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Abstract 

This  thesis  presents  an  unique  methodology  merging  state  of  the  art  Internet  and  distributed 
database  technology  to  support  distributed  simulations  with  programming  language  and  platform 
independence.  Standardized  models  of  Command,  Control,  Communications,  Computers  and  Intel¬ 
ligence  (C4I)  systems  using  Integrated  Definition  (IDEE)  models  and  executable  simulation  objects 
are  placed  in  database  repositories  which  can  be  accessed  and  implemented  over  a  distributed  sim¬ 
ulation  network  using  the  Common  Object  Request  Broker  Architecture  (CORE  A).  The  CORE  A 
distributed  simulation  network  accesses  heterogeneous  distributed  databases  and  performs  dis¬ 
tributed  processes,  and  supports  portability  and  reuse  of  simulation  objects  and  interoperability 
across  operating  systems  and  programming  languages. 
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NET-CENTRIC 


DESIGN  AND  ANALYSIS 
OF 

INFORMATION  SYSTEMS 

L  Introduction 

1.1  Background 

My  experiences  as  a  communications  officer  in  the  U.S.  Army  have  led  me  to  realize  the 
usefulness  of  modeling  and  simulation  in  the  planning  and  analysis  of  communications  networks, 
the  design  of  communications  systems,  and  the  importance  of  including  communications  in  larger 
wargaming  simulations.  As  the  military  becomes  more  “infO’Centric” ,  or  reliant  on  the  timely 
exchange  of  information,  communication  capability  and  reliability  become  increasingly  important 
in  our  mission  planning  and  assessments.  Especially  as  the  U.S.  military  engages  in  world-wide, 
multi-national  operations,  communication  interoperability  and  reliability  are  integral  factors  to  the 
decisions  of  our  military  and  civilian  leaders.  Distributed  modeling  and  simulation  provide  the 
means  to  bring  together  heterogeneous  communications  systems,  and  conduct  trade-off  analysis 
and  optimization  within  the  battlefield  scenario,  to  ensure  the  highest  possible  communications 
interoperability  and  reliability. 

1.2  Motivating  Factors 

1.2.1  Simulation  Disparities.  There  are  two  types  of  simulation  disparities  which  must 
be  overcome  in  future  battlefield  simulations: 

1.  Simulations  which  can  not  interact  with  each  other(31). 
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2.  Simulation  objects  which  represent  the  same  real  world  system,  but  do  not  behave  similarly 
in  different  simulations. 

These  disparities  result  because  of  “stovepipe”  simulation  applications  and  the  creation  of 
simulation  objects  without  consideration  for  their  reuse  or  portability  (Figure  1.1).  Both  disparities 
can  be  overcome  by  using  an  open  architecture  distributed  simulation  network.  Simulations  can 
interact  with  each  other  through  interfaces  which  translate  requests  from  one  programming  language 
to  another.  The  architecture  also  directs  these  requests  to  repositories  where  approved  simulation 
objects  are  stored  (Figure  1.2).  These  simulation  objects  are  based  on  standardized  models  to  ensure 
consistent  behavior,  and  enforcing  the  use  of  approved  objects  ensures  simulation  consistency. 


Simulation  A  Simulation  B 


Simulation  A  cannot 
interact  with  Simulation  B? 


Why  does  the  plane 
fly  backward  in 
Simulation  B? 

Figure  1.1  Disparate  Simulations 

1.2.2  Communications  in  C4I  Systems.  Situational  awareness  on  the  modern  battlefield 
relies  on  information.  The  acquisition,  analysis,  exchange,  presentation  and  use  of  that  informa- 
tion  is  supported  by  C4I  systems.  Communications,  within  the  context  of  C4I,  is  the  key  factor 
or  element  that  links  all  the  other  elements  to  form  a  cohesive  system.  Advances  in  communica- 
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Simulation  A 


Simulation  B 


Figure  1.2  Interactive,  Consistent  Simulations 


tions  technologies  and  methods  together  with  inherent  changing  architectures  make  consideration 
of  system  reliability  and  availability  of  services  key  elements  in  the  decision  making  process.  Un¬ 
less  communications  is  included  as  an  integral  element  of  wargaming,  modeling,  and  simulations, 
decisions  by  our  most  senior  civilian  and  military  leaders  will  be  flawed(24). 

The  importance  of  information  in  the  21st  century,  demands  a  fully  integrated  (horizontally 
and  vertically),  robust,  stable  battle  command  infrastructure.  To  support  the  battle  command 
infrastructure,  complex  management  and  communications  systems  must  provide  the  flexibility  and 
robustness  to  meet  the  needs  of  the  highest  and  lowest  echelons  of  command. 

In  order  to  meet  the  growing  demand  for  information,  the  information  infrastructure  must 
move  away  from  “stove  pipe”  systems(17)  to  seamless,  interoperable,  and  worldwide  systems.  This 
requirement  is  reflected  in  the  U.S.  Army’s  Force  XXI  program.  The  goal  of  this  program  is  to 
create  a  digital  battlefield  which  can  be  used  to  develop  tactics,  doctrine,  training,  and  evaluate  fu¬ 
ture  systems  to  enhance  lethality,  survivability,  tempo,  sustainability,  deployability,  joint/ combined 
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linkages,  and  versatility (5).  To  achieve  the  goal  of  Force  XXI,  communications,  the  backbone  of 
the  21st  century  force,  must  be  realistically  modeled  in  the  digital  battlefield. 

The  digital  battlefield  provides  a  virtual  world  in  which  highly  complex,  distributed  simulation 
can  be  used  to  test  and  analyze  current  and  future  systems.  However,  for  the  digital  battlefield 
to  be  useful,  the  virtual  world  must  realistically  represent  actual  battlefield  characteristics  and 
conditions  faced  by  the  military  today  and  in  the  future.  The  digital  battlefield  must  represent 
how  the  military  organizes  and  communicates  as  a  function  of  the  mission,  environment,  terrain 
and  time. 

In  the  dynamic  environment  of  the  battlefield,  where  mobile  communications  are  being  ex¬ 
tended  deep  into  the  enemy’s  area,  the  need  for  timely  information  over  line-of-sight  radio,  satellite 
and  cable  from  the  farthest  forward  warfighter  to  the  highest  decision  maker  is  increasing.  In 
the  21st  century  force,  communications  dependence  and  its  reliability  become  more  important  as 
the  rear  support  area  may  be  within  the  continental  United  States,  while  the  mission  forces  are 
conducting  operations  around  the  world  (Figure  1.3). 


In  addition,  a  communications  network  is  never  static;  the  network  is  mobile,  changing  topol¬ 
ogy  constantly.  The  environment  is  also  changing.  Weather  and  ionospheric  changes  affect  radio 
paths,  and  external  forces  affect  cable  (more  than  once  a  wire  was  cut  by  the  treads  of  an  armored 
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vehicle  during  Desert  Shield/Desert  Storm).  These  temporally  varying  conditions  must  also  be  re¬ 
alistic  in  the  digital  battlefield  -  reflecting  that  communications  are  especially  susceptible  to  these 
dynamic  changes  in  operations  and  the  environment. 

An  example  scenario  is  shown  in  Figure  1.4  to  illustrate  the  dynamics  involved  in  modern 
scenarios.  An  enemy  tank  (A)  is  observed  by  an  airborne  sensor  system  (B).  Both  the  tank  and 
aircraft  axe  mobile.  The  sensor’s  ability  to  observe  the  tank  is  affected  by  environmental  conditions 
(C)  in  the  path.  The  information  from  the  sensor  is  sent  to  a  U.S.  Army  command  organization  (D) 
which  identifies  the  tank,  via  satellite  (E)  to  a  helicopter  (F)  as  a  target.  A  simulation  would  have  to 
update  the  scenario  based  on  the  mobility  of  the  tank,  aircraft,  and  changes  in  the  environmental 
conditions  which  may  interfere  with  the  sensor’s  “visibility”  and  the  communications  systems. 
These  obstacles,  to  name  only  a  few,  must  be  overcome  to  achieve  true  models  of  the  actual  world 
in  the  digital  battlefield. 


Figure  1.4  Precision  Strike  Scenario 

1.3  Problem  Statement  and  Scope 

1.3.1  Review  of  the  Problem.  C4I  simulations  must  realistically  represent  the  battlefield 
conditions  the  military  faces  today  and  will  face  tomorrow.  These  simulations  must  use  common  ob- 
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jects  to  ensure  consistent  behavior  and  results.  These  simulations  must  also  be  able  to  interact  with 
each  other,  regardless  of  application  programming  language  or  operating  system  inhomogeneities. 
Finally,  communications,  which  is  often  overlooked  in  C4I  simulations(24),  must  be  included  as  the 
backbone  of  any  information  system. 

1.S.2  Scope  of  the  Problem.  In  order  to  develop  an  open  distributed  simulation  net¬ 
work  using  standardized  models  and  simulation  objects  stored  in  repositories,  three  steps  must  be 
completed: 

1.  Model  a  system  described  by  a  given  scenario. 

2.  Develop  simulation  object(s)  from  the  model. 

3.  Develop  a  network  architecture  to  store  and  access  objects  using  heterogeneous  databases, 
over  distinct  geographical  locations,  and  return  results  regardless  of  programming  language 
and  operating  platform  diversities. 

For  the  purposes  of  this  study,  a  narrowly  defined  scenario  is  chosen  to  be  modeled.  The 
scenario  consists  of  receiving  a  signal  at  an  OE-254()/GRC  Antenna  Group  and  measuring  the 
link  margin  at  the  receiver  to  determine  if  the  message  was  received.  Recall  from  Figure  1.4  that 
environmental  conditions  may  affect  the  strength  of  the  signal  actually  received  by  the  antenna. 
This  is  a  representative  scenario  of  all  radiowave  communication  systems.  It  also  uses  a  metric 
to  determine  if  the  information  was  successfully  received,  and  can  be  included  as  part  of  a  larger 
scenario. 

The  contribution  of  this  thesis  then,  is  a  methodology  to  support  standardization  of  the 
modeling  and  simulation  (M&S)  object  development  process,  which  combines  emerging  database 
and  Internet  technologies  to  present  a  realistic,  executable,  distributed  simulation  architecture. 
The  methodology  (as  shown  in  Figure  1.5)  proposes  a  process  to  describe  any  given  scenario  by 
its  specific  architectures,  from  which  persistent  data  and  executable  simulation  objects  can  be 
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M&S  Client 


Figure  1.5  From  the  Real-World  Scenario  to  the  Distributed  Simulation  Architecture 


derived  for  storage  in  databases.  The  information  and  objects  in  these  databases  can  then  be 
accessed  over  the  Internet  using  an  Object  Request  Broker.  By  implementing  this  development 
process  and  distributed  architecture,  simulations  will  meet  the  portability,  interoperability  and 
reuse  requirements  described  in  the  DoD  Modeling  and  Simulation  Master  Plan  (DoD  5000. 59-P) 
and  the  Defense  Modeling  and  Simulation  Office  (DMSO)  High  Level  Architecture  (HLA). 


1.4  General  Approach 

1.4’ 1  Develop  the  Model  The  antenna  example  is  modeled  by  describing  its  technical 
characteristics,  activities,  and  the  internal  and  external  relationships  of  the  system.  The  information 
required  to  describe  the  antenna’s  technical  characteristics  is  modeled  in  an  Entity-Relationship 
(ER)  diagram  according  to  the  IDEFIX  design  method.  An  example  of  an  ER  model  is  shown  in 
Figure  1.6. 

The  ER  model  captures  non-transitory  data  requirements  and  relationships  describing  the 
system.  The  functions  of  the  system  must  then  be  described  in  an  activity  model  according  to  the 
IDEFO  design  method.  An  example  of  an  activity  model  for  a  mobile  radiowave  propagation  path 
is  shown  in  Figure  1.7.  The  examples  are  simplistic  to  give  the  reader  without  a  background  in 
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Once  the  antenna’s  technical  characteristics  have  been  described  in  the  IDEFIX  model,  they 
are  mapped  to  the  schema  of  a  relational  database.  Each  entity  (table)  in  the  database  is  populated 
by  instances  of  particular  antenna  configurations.  For  example,  the  OE-254()/GRC  Antenna  Group 
is  one  instance  of  an  antenna,  and  the  antenna  entities’  attributes  are  populated  using  data  from 
MIL-A-49204A,  ANTENNA  GROUP  OE-254()/GRC  and  Training  Circular  24-24,  Signal  Data 
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References:  Communications-Electronics  Equipment.  Many  antenna  configurations  can  be  repre¬ 


sented  in  a  relational  DBMS  in  this  way,  each  identified  by  a  unique  set  of  attribute  values. 

1.4.2  Develop  Simulation  Object  An  executable  antenna  object  is  created  based  upon  the 
IDEFO  activity  model.  The  object  is  written  in  an  object-oriented  language  such  as  ADA,  C+-h,  or 
JAVA.  A  data  sublanguage  such  as  SQL  is  used  to  access  the  data  stored  in  the  relational  database. 
The  compiled  object  and  any  associated  objects  such  as  images  or  sounds  are  then  stored  in  an 
object  database.  This  method  is  chosen  to  take  advantage  of  the  well  established  relational  model 
for  data  handling,  and  to  maintain  independence  between  the  data  and  the  object.  Therefore,  the 
object  does  not  need  to  be  recompiled  for  minor  changes  in  data  values. 

An  additional  advantage  to  using  an  object-oriented  programming  language  is  the  ability  to 
embed  objects  within  objects.  For  example,  a  super  object  could  be  created  which  would  perform 
the  functions  of  the  airborne  sensor  and  have  embedded  links  to  other  objects.  The  links  would 
call  other  objects  which  would,  for  example: 

•  list  the  technical  references  (TA), 

•  open  a  graphic  of  the  operational  architecture  (OA), 

•  open  a  graphic  of  the  system  architecture  (SA)  and, 

•  retrieve  model  validation  documentation. 

Each  of  these  embedded  objects  could  also  contain  other  embedded  objects  or  links.  This 
concept  of  a  super  object  is  illustrated  in  Figure  1.8. 

1.4.3  Develop  Simulation  Network  Architecture.  These  objects  would  be  available  to 
the  M&S  community  over  the  Internet  by  an  implementation  of  the  Object  Management  Group’s 
CORBA.  A  database  connectivity  bridge  to  the  database(s)  where  the  objects  and  data  are  stored 
would  also  be  required.  The  complexity  and  modularity  of  C4I  systems  makes  object-oriented 
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Figure  1.8  Linking  and  Embedding  Objects 

modeling  and  database  technology  an  obvious  approach.  This  approach  takes  advantage  of  the 
distributed  nature  of  the  Internet;  the  interactive,  multimedia,  and  security  capabilities  of  object- 
oriented  databases;  and  the  data  handling  and  security  capabilities  of  relational  databases. 

1.5  Thesis  Organization 

This  chapter  identifies  the  problem  and  its  scope.  Chapter  2  highlights  published  results 
which  are  synthesized  to  accomplish  the  goals  of  this  thesis.  Chapter  3  elaborates  facets  of  the 
methodology  and  describes  the  process  of  employing  the  methodology  to  solve  the  problem.  Chap¬ 
ter  4  reports  the  results  and  importance  of  the  outcomes  achieved  by  this  research.  Chapter  5 
summarizes  the  problem  and  the  results  of  this  effort  and  makes  recommendations  for  further 
research. 
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IL  Background 


2.1  Introduction 

The  first  chapter  presents  a  brief  explanation  and  context  for  the  problems  faced  by  devel¬ 
opers  of  C4I  systems  simulations.  These  problems  are  described  as  disparate  simulations  which 
cannot  interact  with  each  other,  simulation  objects  which  are  not  standardized  among  simulations, 
and  simulations  which  do  not  account  for  the  fragilities  of  the  communications  backbone.  The 
recommended  methodology  to  solve  these  problems  is  illustrated  by  developing  an  OE-254()/GRC 
Antenna  model  and  executable  simulation  object  which  can  be  accessed  over  the  Internet  using  dis¬ 
tributed  databases  and  a  CORBA  implementation.  The  purpose  of  this  methodology  is  to  ensure 
standardized,  consistent,  simulations  which  can  interact  with  each  other;  regardless  of  differences 
in  underlying  programming  languages  or  operating  systems.  This  chapter  presents  background 
material  essential  to  understanding  the  methodology  described  in  Chapter  Three  and  the  analysis 
of  the  results  in  Chapter  Four. 

A  clear  approach  to  developing  standardized  models  is  to  describe  systems  in  a  standardized 
way.  A  system  can  be  described  by  its  technical  characteristics  and  constraints,  by  its  role  and 
function  in  a  larger  activity,  and  by  its  construction  and  components.  Each  of  these  views  pro¬ 
vides  a  unique  description  of  the  system.  The  Defense  Information  Systems  Agency  (DISA)  and 
the  Office  of  the  Director  of  Information  Systems  for  Command,  Control,  Communications  and 
Computers  (ODISC4)  have  defined  three  architectures  which  describe  C4I  systems:  the  technical, 
operational,  and  system  architecture.  These  three  architectures  together  completely  define  the  sys¬ 
tem  and  form  the  basis  for  the  system  model.  ODISC4  has  adopted  the  IDEF  model  method  to 
capture  and  communicate  the  operational  architecture  of  the  system.  The  IDEF  models  serve  as 
tools  to  develop  executable  simulation  objects  and  map  relational  and  object-oriented  databases. 
The  Internet  provides  the  infrastructure  to  access  and  process  the  simulation  object  and  system 
definition  over  a  distributed  network.  The  following  topics  are  covered  in  this  chapter:  1)  The 


2-1 


technical,  operational,  and  system  architectures,  2)  IDEF  modeling,  3)  Integrating  the  three  ar¬ 
chitectures  into  an  executable  simulation,  4)  Distributed  databases  and  the  Internet,  and  5)  The 
three-tiered  network  architecture. 


2.2  The  Technical,  Operational,  and  Systems  Architecture 

Figure  2.1  illustrates  the  relationship  between  the  three  architectures.  Primary  inputs  to  the 
systems  architecture  are  the  operational  architecture  (defining  the  process  and  task  flows,  logical 
connectivities  and  performance  bounds  to  be  supported)  and  the  technical  architecture  (defining 
the  protocols  and  standards  mandated  for  use  to  ensure  interoperability  and  seamless  connectivity 
between  these  component  systems).  The  technical  architecture  provides  the  “building  code”  to  the 
systems  architecture(29). 
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Figure  2.1  Architecture  Interfaces  (29) 


Figure  2.2  illustrates  the  development  of  the  systems  architecture  from  the  operational  ar¬ 
chitecture  within  the  constraints  (i.e.,  “under  the  umbrella”)  of  the  technical  architecture.  The 
operational  architecture  is  developed  in  concert  with  the  US  Army  Training  and  Doctrine  Com¬ 
mand  (TRADOC)  schools  and  centers  and  consequently  incorporates  current  doctrine.  The  oper¬ 
ational  architecture  describes  the  information  exchange  requirements,  force  structure,  movement 
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Figure  2.2  Systems  Architecture  Development  (29) 


plans,  and  logical  connectivity  among  organizations  and  personnel.  These  are  necessary  inputs  to 
the  system  architecture.  This  information  captures  connectivity  requirements,  informational  con¬ 
tent  of  exchanges,  frequency,  speed,  perishability,  impact  of  failure  and  security  requirements.  The 
model-based  data  repository  (C4RDP,  now  known  as  the  C2  Core  Data  Model  (C2CDM)  )  serves 
two  purposes:  1)  it  provides  standardization  of  model  entities  and  2)  it  takes  the  product  of  the 
operational  architecture  as  an  input,  and  transforms  it  to  the  format  of  the  representation  needed 
as  input  to  the  system  architecture.  The  system  architecture  then  overlays  system  solutions  to 
the  information  requirements  to  produce  the  physical  and  communications  structure.  In  short,  the 
operational  architecture  represents  the  information  exchange  perspective,  and  the  resultant  system 
architecture  captures  how  the  hardware  and  software  support  those  needs. 


2.2.1  Operational  Architecture.  The  operational  architecture  describes  who  needs  to 
exchange  information,  what  information  needs  to  be  exchanged,  and  how  that  information  will  be 
used.  This  architecture  describes  the  functions,  processes  and  data  required  to  meet  the  needs 
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of  the  warfighter.  The  operational  architecture  is  captured  and  communicated  using  the  IDEF 
modeling  methods  described  in  Federal  Information  Processing  Standards  (FIPS)  183  and  184. 

The  IDEFO  method  is  used  to  specify  function  models,  which  are  “what  do  I  do”  models. 
The  IDEFO  models  let  the  modeler  portray  a  view  of  the  process  using  inputs  (I),  controls  (C), 
outputs  (0),  and  mechanisms  (M)  (referred  to  as  ICOMs).  Inputs  to  an  activity  consist  of  resources 
consumed  or  transformed  by  a  process  and  state  outputs  from  other  activities.  Controls  are  the 
standards,  policies,  and  guidelines  that  constrain  and  guide  the  process.  Outputs  are  the  products 
created  by  the  transformations  of  the  inputs  by  the  process.  Mechanisms  are  the  agents  (people, 
manual  tools,  automated  tools,  etc.)  that  accomplish  the  actions  delineated  within  the  process. 
Once  these  blocks  are  defined,  their  relationship  to  the  process  and  the  “flow”  of  the  input  through 
the  controls  and  mechanisms  to  its  final  output  must  be  defined(15,  26).  An  example  of  an  activity 
model  for  a  radio  path  is  illustrated  in  Figure  2.3. 


Figure  2.3  Example  Activity  Model  (IDEFO) 


The  IDEFIX  method  is  based  on  an  ER  model(25)  and  used  for  data  modeling.  It  captures 
the  logical  view  of  the  activity’s  data.  It  is  a  method  for  logical  database  (library)  design  once  the 
information  requirements  are  known.  The  focus  is  on  the  actual  data  entities,  their  attributes,  and 
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their  relationships  to  other  entities  in  the  information  system  to  be  developed.  This  description  of 
the  system  supports  the  development  of  the  operational  component  and  system  modules  once  the 
primitive  ICOMs  have  been  defined(15,  25,  21,  8).  An  example  of  an  information  entity  relationship 
model  is  illustrated  in  Figure  2.4. 


Figure  2.4  Information  Model 


Therefore,  we  can  take  a  scenario,  or  an  operational  concept,  and  break  it  into  its  functional 
(IDEFO)  and  physical  architectures  (IDEFIX).  An  operational  architecture  is  obtained  by  mapping 
a  functional  architecture  onto  a  physical  one,  for  a  given  operational  concept  (Figure  2.5).  The 
operational  architecture  shows  the  allocation  of  resources  to  functions,  the  flow  of  data,  and  the 
order  in  which  functions  are  performed(3). 

The  operational  architecture  is  then  used  to(12,  5): 

•  Conceptualize  operational  requirements 

•  Identify  unsat isfled  requirements 

•  Prioritize  requirements 

•  Plan  evolution  of  systems 

•  Develop  data  standards 
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Figure  2.5  Operational  Architecture  Development  (29) 

•  Measure  resource  utilization 

•  Identify  interoperability  requirements 

•  Drive  the  technical  architecture 

2,2.2  System  Architecture.  The  system  architecture  shows  the  specific  hardware  needed 
and  network  topology  to  provide  the  connectivity  required  in  the  operational  architecture.  Both 
architectures  are  very  closely  linked.  The  system  architecture  is  a  description  of  the  physical 
connectivity  of  an  information  system,  which  includes:  identification  of  all  equipment  (radios, 
switches,  terminals,  computers,  inter- networking  devices,  and  local  area  nets  (LANs)),  their  physical 
deployment,  the  specification  of  such  parameters  as  the  bandwidth  required  on  each  circuit,  and 
the  description  of  the  technical  characteristics  and  interconnection  of  all  parts  of  an  information 
system(5).  The  system  architecture  is  made  up  of  the  top-level  diagram  in  the  network  model  or 
simulation  and  each  successive  component-level  diagram  in  a  top-down  system  of  systems  model. 

The  system  architecture  permits  trade-off  analysis  to  optimize  overall  network  and  system 
performance  within  the  performance  bounds  defined  in  the  operational  architecture(5).  This  top- 
level  view  of  the  information  system  indicates  to  the  mission  and  network  planner  when  the  system 
is  meeting  performance  requirements  or  when  new  requirements  or  unsatisfied  requirements  must 
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be  addressed.  The  requirements  in  the  operational  architecture  drive  this  feedback  to  the  planner. 
However,  the  system  diagram  must  also  identify  the  impact  on  the  operational  architecture  as  the 
system  degrades  as  well  as  the  component  (s)  in  the  technical  architecture  which  are  restricting  the 
system  performance.  This  architectural  relationship  is  illustrated  in  Figure  2.6  (5,  29). 


Operational  Architecture 
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Figure  2.6  Architecture  Relationships  (29) 


2.2.3  Technical  Architecture.  The  technical  architecture  is  defined  as  a  minimal  set  of 
rules  governing  the  arrangement,  interaction,  and  interdependence  of  the  parts  of  an  information 
system.  The  technical  architecture  does  not  say  what  to  build  (that  is  defined  by  the  planner 
in  the  operational  architecture),  nor  does  it  say  how  to  build  (that  is  defined  by  the  planner 
in  the  system  architecture),  but  it  does  say  that  when  you  build  you  must  adhere  to  the  set  of 
rules /protocols /standards  that  it  specifies.  The  standards  in  the  technical  architecture  establish  the 
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framework  for  achieving  interoperability  and  commonality  among  component  hardware/ software 
and  seamless  communications  connectivity  between  battlefield  elements(5). 

The  technical  architecture  provides  the  “building  code”  for  the  systems  architecture  to  meet 
the  requirements  in  the  operational  architecture.  It  addresses  the  technical  aspects  of  how  to  inte¬ 
grate  the  command,  control,  communications,  computers  and  intelligence  (C4I)  systems  to  achieve 
the  operational  requirements  set  forth  by  the  operational  architecture.  The  technical  architecture 
establishes  the  spectrum  of  available  and  approved  system  implementation  options.  The  tech¬ 
nical  architecture  therefore  consists  of  standards  which  can  be  referenced  (i.e.,  COE,  C2CDM, 
use  of  ADA,  HCI  standards,  MILSTD-188-220  and  VMF)(5)  and  standardized  components  which 
meet  these  technical  standards.  Upon  completion,  the  technical  architecture  identifies  a  frame  of 
standards  and  includes  top-level  system  specifications,  architecture  wiring  diagrams  for  technical 
interface  specifications,  identification  of  transactions  between  equipment  and  the  protocols  used  in 
this  interface,  and  supporting  performance  and  modeling  results(12). 

The  Army  technical  architecture  consists  of  four  elements:  1)  the  information  processing 
profile,  2)  the  information  transport  profile,  3)  information  standards,  and  4)  human-computer  in¬ 
terface  (HCI)  (35).  The  information  processing  profile  details  standards  consistent  with  commercial 
and  Department  of  Defense  (DoD)  Technical  Architecture  Framework  for  Information  Management 
(TAFIM)(10).  It  provides  guidance  for  developing  technical  information  system  architectures  at 
all  organizational  levels  of  DoD  environments  that  share  functions  and  data.  The  information 
transport  profile  defines  the  communications  support  required  to  provide  seamless,  reliable,  and 
timely  data  exchange  between  users,  regardless  of  the  specific  communications  system(s)  used  to 
access  the  network  infrastructure.  A  communication  system  conforming  to  the  Open  System  Inter¬ 
connection  (OSI)  Reference  Model  is  an  example  of  this  type  of  information  system.  Information 
standards,  such  as  standardized  data  elements  and  message  format  standards,  provide  the  basis 
for  sharing  information  across  gateways  using  common  interfaces.  These  standards  are  recorded  in 
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DOD  8320.1  series  guidance  (Standard  Data  Elements  for  Automated  Information  Systems  (AIS) 
Design  and  Development),  Military  Standards  (MIL-STD),  and  commercial  Internet  standards. 
Most  notable  examples  for  military  systems  standardization  are  the  Protocol  Data  Unit  (PDU) 
and  the  LINK16/ Variable  Message  Format  (VMF)  (replacement  to  the  United  Service  Message 
Text  Format  (USMTF)).  Finally,  standardizing  the  HCI  to  attain  a  user  interface  that  presents 
a  common  appearance  and  behavior  across  joint  service  systems  requires  a  common  set  of  HCI 
standards  and  a  common  approach  to  implement  them.  Volume  8  of  the  DOD  TAFIM  contains 
the  DOD  HCI  Style  Guide.  This  style  guide  sets  the  basic  standards  for  graphical  HCIs. 

The  technical  architecture  describes  the  major  aspects  of(12): 

•  Functions  which  must  be  performed  to  meet  required  operational  capabilities 

•  Information  (e.g.,  databases,  data  elements  and  data  definitions,  images,  sound,  text,  etc.) 

•  Applications  (e.g.,  E-Mail,  maps,  targeting  systems,  data  collection  systems,  control  systems, 
mission  planning  systems,  office  tools) 

•  Technology  (e.g.,  hardware,  systems  software,  standards,  protocols,  and  communications) 

The  antenna  described  in  the  previous  section  has  predetermined  technical  architecture  con¬ 
straints  and  requirements.  Once  these  standards  are  captured  and  represented  in  the  IDEF  models 
of  the  operational  architecture,  the  information  can  be  stored  in  a  model  library  or  repository. 
If  the  technical  architecture  does  not  allow  the  system  to  meet  the  operational  requirements,  the 
operational  requirements  must  be  changed.  For  example,  a  network  planner  may  be  using  the 
antenna  in  a  communications  network.  However,  the  antenna  may  not  have  the  gain  required  (as 
set  by  the  technical  architecture)  to  meet  link  margin  requirements  across  a  specific  path  in  the 
network.  A  common  change  to  the  system  architecture  by  the  network  planner  to  maintain  sat¬ 
isfactory  performance  in  the  network  is  in  the  network  topology.  For  example,  a  platform  may 
move  from  communicating  by  one  means  (e.g.,  LOS)  to  another  (TAGS AT,  SATCOM)  or  the  size 
of  the  network  may  be  altered  by  adding  or  dropping  nodes  to  increase  reliability.  If  the  network 
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cannot  be  modified  to  maintain  communications  while  meeting  the  requirements  of  the  operational 
architecture,  the  operational  architecture  must  be  examined  to  measure  the  effect  of  a  loss  of  com¬ 
munications.  The  result  may  be  a  different  tactic  or  a  new  requirement.  Finally,  an  operational 
requirement  may  be  met  through  an  improvement  in  the  technical  architecture  which  removes  a 
constraint  that  prevented  the  performance  of  the  system  from  meeting  the  operational  require¬ 
ment.  The  interrelationships  of  the  architecture  products  discussed  in  this  section  are  illustrated 
in  Figures  2.7  and  2.8. 
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Figure  2.7  Architecture  Products  (29) 


2.3  Integrating  the  Three  Architectures  into  Executable  Simulation  Objects 

The  requirements  for  the  distributed  simulation  architecture  are  similar  to  the  requirements 
described  in  the  Information  Mesh  project  by  Sollins  of  MIT  and  Dyke  of  Trilogy  Development 
Group  for  a  General  Information  Architecture.  The  General  Information  Architecture  lays  out  a 
common,  extremely  general  substrate  that  sits  between  network-based  systems  such  as  distributed 
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Figure  2.8  Architecture  Product  Interrelationships  (29) 


programming  or  database  environments  and  network  transport  protocols  such  as  TCP  or  other 
bit  stream  protocols.  The  intention  of  the  information  mesh  is  to  provide  sharing  and  exchange 
of  potentially  persistent  information  independent  of  the  underlying  platform  operating  systems, 
programming  languages,  transport  protocols  and  related  infrastructure.  Although  the  methodology 
uses  the  Object  Management  Group’s  (OMG)  CORBA,  the  requirements  of  the  General  Information 
Architecture  are  identical  to  the  requirements  for  the  distributed  simulation  network  and  are  listed 
here(33): 


•  Multiplicity.  One  must  be  able  to  express  relationships  between  two  or  more  objects. 

•  Link  Typing.  It  is  important  to  be  able  to  express  the  nature  of  a  link  or  relationship  ex¬ 
tensively  and  with  unlimited  scope,  in  order  to  support  evolution  in  the  representation  of 
knowledge. 

•  Linking  into  the  structure  of  objects.  In  order  to  provide  generality  and  flexibility  in  linking 
objects,  it  is  necessary  to  be  able  to  link  components,  aspects,  views,  or  parts  of  objects  to 
each  other. 
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•  Linking  to  links.  There  are  situations  in  which  the  ideas  being  linked  may  be  themselves 
links.  We  must  be  able  to  relate  to  links. 

•  Composition  of  objects.  Relationships  can  be  divided  into  those  that  are  intrinsic  or  integral 
to  an  object  and  those  that  are  not.  If  a  relationship  is  intrinsic  to  an  object,  that  composite 
object  is  unable  to  behave  in  the  intended  manner  without  its  components.  In  contrast, 
other  extrinsic  relationships  do  not  have  a  direct  bearing  on  whether  or  not  the  related 
objects  behave  as  expected.  It  is  important  to  be  able  to  express  this  distinction  and  support 
composite  objects. 

•  Support  existing  models  of  linking.  Existing  systems  define  the  minimum  set  of  characteristics 
we  must  be  able  to  support. 

The  links  and  composition  of  objects  are  the  relationships  and  ICOMs  in  the  IDEE  models 
discussed  in  previous  sections.  These  links  and  relationships  can  then  be  encoded  into  objects 
through  the  methods  and  data  sublanguage  of  an  object-oriented  programming  language.  The 
objects  can  then  be  stored  in  an  object-oriented  database  and  the  data  values  in  a  relational 
database.  The  advantage  to  this  independence  is  being  able  to  alter  data  values  without  having 
to  recompile  objects.  The  disadvantage  is  they  must  be  managed  jointly,  so  if  the  antenna  object 
was  deleted  from  the  object  database,  the  antenna  records  or  tables  would  also  need  to  be  deleted 
from  the  relational  database.  This  weakness  is  resolved  by  using  a  multi-database  management 
system  (MDBMS).  An  MDBMS  would  manage  relational  and  object-oriented  databases,  or  a 
hybrid  database  which  combines  the  two.  A  great  degree  of  research  is  currently  being  conducted 
to  perform  this  service,  and  some  proprietary  systems  have  been  produced  to  varying  degrees  of 
success (36).  However,  for  the  purposes  of  this  research,  the  databases  must  be  carefully  managed 
by  the  Database  Administrator  to  ensure  they  are  kept  current. 
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2.4  Distributed  Databases  and  the  Internet 


Having  the  data  and  objects  needed  for  a  simulation  stored  in  databases  is  only  useful  if 
they  can  be  called  and  executed  by  any  user,  even  when  non-collocated  with  the  system  hosting 
the  objects.  Relational  database  management  systems  (RDBMS)  are  commonly  accessed  remotely 
through  a  client/server  architecture  today  (see  Figure  2.9)(2).  These  applications  are  often  propri¬ 
etary  and  operating  system  specific.  However,  the  recent  introduction  of  open  database  connectivity 
(ODBC)  applications  such  as  SQL*Net  have  allowed  clients  to  connect  to  different  vendors’  SQL 
databases  over  networks,  independent  of  the  client’s  operating  system  (0/S)  platform. 


Figure  2.9  Today’s  RDBMS  Client/Server  (2) 


Object-oriented  database  management  systems  (ODBMS)  are  also  accessible  in  the  same 
manner  as  relational  databases(20,  19)  (see  Figure  2.10).  The  object-oriented  database  provides 
the  capability  to  store  compiled  object-oriented  programming  files  and  multimedia  data  types  that 
relational  databases  cannot.  By  combining  the  use  of  object-oriented  databases  and  relational 
databases,  a  multidimensional  database  is  created  that  is  transparent  to  the  client.  An  example  of 
this  multidimensional  database  system  is  shown  in  Figure  2.11. 
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Figure  2.10  Today’s  Object  DBMS  Client/Server  (2) 


Figure  2.11  Multidimensional  Database  Example 


2-14 


The  desire  for  the  ability  of  a  single  client  application  to  access  more  than  one  database 
motivates  the  creation  of  distributed  databases.  A  properly  implemented  distributed  database 
system  has  the  following  characteristic(ll): 

. . .  full  support  for  distributed  database  implies  that  a  single  application  should  be  able 
to  operate  transparently  on  data  that  is  spread  across  a  variety  of  different  databases, 
managed  by  a  variety  of  different  DBMSs,  running  on  a  variety  of  different  machines, 
supported  by  a  variety  of  different  operating  systems,  and  connected  by  a  variety  of 
different  communication  lietworks-where  the  term  transparently  means  that  the  appli¬ 
cation  operates  from  a  logical  point  of  view  as  if  the  data  were  all  managed  by  a  single 
DBMS  running  on  a  single  machine. 

In  a  distributed  database  system,  the  client  may  access  a  remote  object  database  and  retrieve 
a  program  which  calls  data  from  another  remotely  located  relational  database.  The  program  may 
be  processed  at  the  client’s  machine,  the  local  host,  or  on  a  remote  host,  meaning  not  only  is  the 
information  distributed,  but  the  processing  is  also  distributed.  This  sharing  of  information  and 
processing  has  the  advantage  of  using  resources  efficiently,  if  managed  properly.  An  example  of  a 
distributed  database  system  is  shown  in  Figure  2.12 
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Figure  2.12  Distributed  Database  Example 
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2.5  The  Three-tiered  Network  Architecture 


The  client/server  terminology  of  the  past  becomes  vague  when  discussing  distributed  systems 
over  the  Internet.  The  client  in  one  transaction  could  be  the  server  for  a  client  in  the  next  trans¬ 
action.  Therefore,  the  requester  for  any  transaction  is  considered  the  client  and  the  applications 
making  the  request  and  providing  the  user  interface  are  considered  the  front-end  or  client  side. 
The  applications  which  retrieve  the  information  requested  by  the  client  are  considered  to  be  the 
back-end.  An  example  of  a  back-end  application  is  the  database  management  system  (DBMS).  The 
software  that  acts  as  an  intermediary  between  the  client’s  application  program  and  the  DBMS  is 
called  middlewareiy).  An  example  of  such  middleware  is  the  ODBC.  This  grouping  of  the  software 
with  some  examples  shown  is  illustrated  in  Figure  2.13 
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Figure  2.13  Three-tiered  Architecture  Example 
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2, 6  Summary 


This  chapter  has  provided  an  overview  of  the  operational,  technical  and  system  architectures 
used  to  model  C4I  systems.  Additionally  this  chapter  describes  and  motivates  the  terminology  and 
structure  of  the  Internet  architecture  which  allows  interoperability  and  portability  of  objects  and 
data,  via  IDEF  modeling,  relational  and  ODBMS,  as  well  as  the  OMG  CORBA  standard.  The  next 
chapter  describes  the  antenna  model  and  object,  creating  relational  database  tables  to  store  the 
persistent  data  identified  in  the  antenna  IDEFIX  model  and  storing  the  object-oriented  antenna 
program  in  an  object  database.  The  structure  of  each  tier  is  then  developed  to  allow  the  antenna 
object  to  be  accessed  and  implemented  as  part  of  a  client’s  simulation  application. 
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III.  Methodology 


3.1  Introduction 

The  first  chapter  presents  a  brief  historical  background  of  the  problems  faced  by  simulators 
of  C4I  systems,  and  states  the  problem  to  be  solved.  The  second  chapter  presents  background 
material  essential  to  understanding  the  solution  presented  in  this  chapter  and  the  analysis  of  the 
architecture  in  Chapter  Four.  This  chapter  presents  the  methodology  used  to  develop  the  models, 
executable  objects  and  distributed  architecture  for  distributed  simulations. 

3.2  Developing  the  Operational  Architecture 

The  ER  model  and  activity  model  are  developed  jointly  to  describe  the  operational  archi¬ 
tecture.  Although  each  can  be  developed  independently,  the  process  of  developing  them  jointly 
serves  to  check  that  each  is  complete.  Later,  when  the  antenna  model  is  used  to  develop  relational 
database  tables,  and  object-oriented  code,  the  advantage  to  developing  these  IDEF  models  jointly 
will  become  obvious. 

In  this  thesis,  the  illustrative  scenario  is  defined  as  the  reception  of  a  message  using  an  OE- 
254() /GRC  Antenna  Group  and  compatible  receiver.  The  modeler  should  identify  the  agents  in 
this  scenario  as  an  antenna,  receiver  and  radiowave  propagation  path.  The  receiver  object  which 
will  require  information  from  the  antenna  and  a  path  object  will  pass  information  to  the  antenna 
(see  Figure  3.1). 


Figure  3.1  Information  Flow  Diagram 
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Recall  from  Figure  1.4,  the  path  is  not  assumed  to  be  degradation  free.  To  determine  if  the 
message  was  received  in  a  simulated  transmission,  the  link  margin  is  calculated  given  a  required 
bit  energy  per  noise  power  spectral  density.  The  link  margin  is  calculated  using  the  Equation  3.1 
(see  appendix  C): 


M  = 


(3.1) 


where  M  is  the  link  margin,  Et  is  the  bit  energy,  No  is  the  noise  power  spectral  density,  and 
all  quantities  are  in  dB. 


S.2.1  Developing  the  Entity  Relationship  Model  IDEFIX  is  used  to  produce  a  graphical 
information  model  which  represents  the  structure  and  semantics  of  data  relevant  to  an  enterprise  or 
system.  This  model  can  then  be  used  to  develop  relational  databases  which  contain  the  information 
used  by  simulation  objects,  and  the  embedded  SQL  code  for  the  host  simulation  language.  Each 
block  in  the  IDEFIX  model  represents  an  entity.  An  entity  represents  an  item  of  interest  to  the 
modeler  from  a  “relational”  perspective.  An  entity  is  described  by  a  set  of  attributes.  An  attribute 
is  a  property  or  characteristic  that  is  common  to  some  or  all  of  the  instances  of  an  entity.  An 
attribute  draws  legal  values  from  a  natural  or  prescribed  domain  of  values,  consistent  with  the 
system  and  scenario  being  modeled.  A  domain  is  a  named  set  of  data  values  all  of  the  same 
data  type,  upon  which  the  actual  value  for  an  attribute  instance  is  drawn.  Every  attribute  must 
be  defined  on  exactly  one  underlying  domain.  Multiple  attributes  may  be  based  on  the  same 
underlying  domain. 

Often,  entities  in  the  real  world  are  related  to  other  entities.  For  example,  one  entity  may  be 
the  component  of  another  entity.  A  relationship  is  an  association  between  two  entities  or  between 
instances  of  the  same  entity.  It  is  important  to  identify  the  relationships  between  entities.  The 
relationships  are  part  of  the  definition  of  the  system  and  help  to  properly  manage  and  access 
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information  about  the  system  which  may  be  stored  in  many  entities.  IDEFIX  models  can  become 
quite  large  as  entities  and  relationships  are  identified,  as  shown  in  the  JDBE  ER  antenna  model  in 
Appendix  A,  but  a  simple  model  for  this  scenario  is,  shown  in  Figure  3.2  (25). 
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Figure  3.2  IDEFIX  Antenna  ER  Diagram 

The  IDEFIX  diagram  supports  defining  relational  database  elements  which  are  populated 
with  instances  and  values  representing  the  real  world  system  being  modeled.  For  example,  the 
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ANTENNA-TYPE  table  for  the  OE-254()/GRC  is  shown  in  Figure  3.3.  All  the  attribute  values 
represent  the  persistent  data  of  the  antenna  system  of  interest  for  the  level  of  abstraction  required 
by  the  scenario  (all  lengths  and  distances  are  in  meters,  and  all  weights  are  in  pounds). 
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Figure  3.3  ANTENNA.TYPE  Table  for  the  OE-254()/GRC 


Each  table  captures  the  persistent  data  from  the  technical  specifications  and  operational 
architecture  products  (refer  to  Figure  2.7)  relating  to  the  OE-254()/GRC  antenna  and  relevant  to 
the  scenario  provided.  However,  the  relational  database  is  not  an  executable  system  and  does  not 
capture  the  process,  function,  or  activity  of  the  antenna.  For  this  purpose,  the  IDEFO  activity 
model  is  developed. 


3,2.2  Developing  the  Activity  Model  The  IDEFO  model  begins  with  only  one  block 
identifying  the  complete  activity;  this  is  the  top-level  diagram  (Figure  3.4)  (26). 

The  single  function  represented  on  the  top-level  context  diagram  is  decomposed  into  its  major 
sub-functions  as  shown  in  Figure  3.5. 

These  diagrams  describe  the  basic  functions  of  the  antenna  required  to  calculate  the  link 
margin  based  on  the  scenario  provided. 
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Figure  3.4  IDEFO  OE-254/GRC  Top-level  (A-0)  Diagram 


Figure  3.5  IDEFO  OE-254/GRC  (A-0)  Child  Diagram 
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3.3  Integrating  the  Technical  Architecture 

The  activity  model  presented  in  the  last  section  describes  the  basic  functions  of  the  antenna; 
however,  the  constraints  of  the  technical  architecture  have  not  been  included.  For  example,  the 
frequency  range  of  the  antenna  is  specified  to  be  between  30  and  88  MHz  by  the  technical  architec¬ 
ture.  To  achieve  operational  realism,  it  would  be  useful  to  verify  that  the  signal  received  across  the 
path  has  a  center  frequency  in  the  specified  range.  A  similar  constraint  could  be  added  to  verify 
that  the  receiver  uses  the  same  frequency  range  as  the  antenna  and  that  it  is  a  type  of  receiver 
which  can  use  the  OE-254()/GRC  antenna  system.  These  constraints  are  included  in  the  activity 
model  as  f  and  Receiver-Type,  as  shown  in  Figures  3.6  and  3.7  (see  Appendix  B  for  IDEFO  model 
documentation). 


Figure  3.6  IDEFO  OE-254/GRC  (A-0)  Diagram  with  Constraint 


These  constraints  ensure  that  incompatible  radio  systems  with  different  frequency  ranges  are 
not  connected  across  the  path  in  a  model,  or  if  they  are,  the  simulation  does  not  allow  the  radios 
to  communicate. 
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Figure  3.7  IDEFO  OE-254/GRC  (A-0)  Child  Diagram  with  Constraint 
S.Ji.  Developing  the  System  Architecture 

The  system  architecture  is  designed  to  meet  the  requirements  and  functions  of 
ational  architecture  within  the  constraints  of  the  technical  architecture.  An  example 
representation  of  the  OE-254()/GRC  system  architecture  is  shown  in  Figure  3.8  (Graphic  modified 
from  TC24-24).  The  input  parameters  from  the  path,  specified  by  the  operational  architecture 
(EIRP  —  Lsj  f,  and  Receiver  Type),  are  included  on  the  graph  by  the  antenna  section.  The  com¬ 
ponents  of  the  antenna,  the  antenna’s  frequency  range,  loss  characteristics  and  cable  length  are 
specified  by  the  technical  architecture.  The  system  architecture  is  the  combined  view  dictating 
the  height  required  to  receive  the  signal  (within  the  height  specified  by  the  technical  architecture), 
the  number  of  mast  sections  required,  the  distance  between  the  antenna  and  receiver  based  on  site 
conditions,  etc. 
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parameters  it  receives  from  the  path  and  receiver  objects  are  in  fact  valid  values. 
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Assume  an  antenna  class  already  exists  and  has  been  defined.  The  first  step  is  to  create  and 
initialize  the  OE254JPath  object  (18,  37,  11): 

Antenna  OE254_Path  =  new  Antenna(); 

Now,  to  get  the  frequency  range  of  the  antenna  from  the  ANTENNA-TYPE  table  in  the 
Relational  database: 

/*  connect  to  the  database  system  using  the  database  connectivity  method,  location, 

/*  id,  password  and  name  of  the  database. 

database.connect(“ODBC”,  “FTGORDON”,  “myname”,  “mypwd”,  “ANTENNA”) 

if  (!database.connected())  { 

write  (“Unable  to  connect  to  the  database.”)} 

/*  SQL  to  get  frequency  range 
select  ANTENNA.Ant-Low_Ereq 
into  :LowFreq 
from  ANTENNA-TYPE 

where  ANTENNA.Ant-Nomenclature  =  “OE-254()/GRC” 

select  ANTENNA. Ant-High-Freq 
into  :HighPreq 
from  ANTENNA 

where  ANTENNA.Ant-Nomenclature  =  “OE-254()/GRC” 

/*  end  SQL 

if  (PathFreq  <  LowFreq  OR  >  HighPreq)  { 

write  ( “Received  frequency  is  not  within  operating  range  of  the  antenna.”  } 

Also  we  want  to  check  an  array  named  receivers  in  an  object-oriented  database  to  verify  that 
the  receiver  is  compatible  with  the  antenna(9): 

/*  SQL  to  get  NSN  of  the  receiver 
select  ANTENNA.MaterialJD 
into  :OE254ID 
from  ANTENNA-TYPE 
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where  ANTENNA.AntJSTomenclature  =  “OE-254()/GRC” 
select  RF_EQUIPMENT.MateriaUD 
into  :Receiver 

from  ANTENNAXEADJN_ASSY 

where  ANTENNA.Material JD  =  OE254ID  /*NSN  of  OE-254 
/*end  SQL 

database.connect(“ODBC”,  “FTGORDON”,  “myname”,  “mypwd”,  “COMPATIBIL¬ 
ITY”) 

if  (!database.connected())  { 

write  (“Unable  to  connect  to  the  database.”)} 

/*  OQL  to  check  array 

if  (lexists  Receiver  in  COMPATIBILITY.receivers :  COMPATIBILITY.antenna  =  OE254ID) 

{  write( “Receiver  not  compatible  with  OE-254()/GRC  antenna  group.”)  } 

/*  end  OQL 

The  embedded  query  languages  serve  two  purposes.  Once  the  program  has  been  written, 
changes  to  the  persistent  data  do  not  require  changes  to  the  program  and  subsequent  recompiling 
and  linking.  The  reliance  on  the  database  improves  data  management  and  use  of  the  current 
standardized  values. 

3.6  Storing  the  OE254-Path  Object  in  the  Object  Database 

The  antenna  object  is  stored  in  the  object  database  with  a  unique  object  identity  (OID). 
Object  identity  is  the  property  of  an  object  that  distinguishes  it  from  all  other  objects(19),  even 
similar  or  duplicate  objects.  Each  object  in  the  database  must  have  a  unique  identity  for  the 
ODBMS  to  recognize  which  object  is  being  requested.  This  is  especially  important  when  many 
duplicate  objects  are  being  used  in  a  scenario.  For  example,  in  a  communication  network,  several 
OE-254()/GRC  antenna  systems  may  be  employed.  The  ODBMS  must  be  able  to  distinguish  each 
duplicate  object  as  a  unique  instance  of  an  OE-254()/GRC  antenna  system. 
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Objects  may  be  shared  by  other  objects.  For  example,  a  graphic  file  with  a  universal  antenna 
symbol  may  be  shared  by  all  antenna  objects  for  display  in  a  client’s  GUI  simulation  application. 
In  some  directory  systems  (e.g.,  DOS),  to  share  a  file  among  directories,  the  file  must  be  copied  to 
each  directory.  To  avoid  the  redundancy  that  results  and  the  requirement  for  the  user  to  maintain 
consistency  by  making  changes  to  each  copy  every  time  an  update  is  made,  the  identity  method 
must  allow  linking  between  objects. 

Several  methods  are  appropriate  to  ensure  a  unique  OID.  One  method  is  to  use  the  name 
of  the  object’s  creator,  birth  place  of  the  file,  and  a  file  name.  A  global  repository  identifies  each 
object  this  way,  and  the  birthplace  repository  tracks  the  location  of  the  file  in  case  it  is  ported  to 
another  location.  Type-State-Identity  Trichotomy  (19)  is  also  used  to  uniquely  identify  objects. 
Using  this  method,  the  antenna  object  is  identified  by  its  class,  instance  and  state.  For  example, 
the  OE-254()/GRC  antenna  object  is  stored  as  OE254JPATH  and  the  OID  “path”  notation  is 
24thIDCmdNet/NodeEl/OpsSINCGARS/ANTENNA/RECEIVE/OE254J^ATH  (see  Figure  3.9). 
If  the  antenna  object  is  copied,  or  ported  to  another  location,  it  is  still  uniquely  identified  by 
changing  the  name  of  the  net,  node,  or  communication  system. 

3. 1  Using  a  CORE  A  ORB  to  Request  and  Implement  Objects 

The  OE254JPATH  object  is  made  available  to  distributed  simulation  clients  using  the  CORBA 
shown  in  Figure  3.10  (27).  The  following  sections  explain  the  function  of  each  component,  from 
requesting  the  object  in  the  client’s  simulation  application  through  returning  results  to  the  simu¬ 
lation. 
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Figure  3.9  Semantic  Model  for  a  Communication  Net. 


Figure  3.10  The  Common  Object  Request  Broker  Architecture  for  a  Distributed  Simulation 


3.1.1  Requesting  the  AntJPath  Object  from  the  Simulation.  The  simulation  executing 
on  a  client  requests  an  object  using  an  object  reference.  An  object  reference  is  a  token  that 
may  be  invoked  or  passed  as  a  parameter  to  an  invocation  on  a  different  object.  Invocation  of 
an  object  involves  specifying  the  object  to  be  invoked,  the  operation  to  be  performed,  and  the 
parameters  to  be  given  to  the  operation  or  returned  from  it.  The  client  knows  only  the  logical 
structure  of  the  object  according  to  its  interface,  and  experiences  the  behavior  of  the  object  only 
through  the  object’s  invocation.  Clients  access  object-type-specific  stubs  as  library  routines  in  their 
program  (see  Figure  3.11).  The  client  program  thus  sees  routines  callable  in  the  normal  way  in 
its  programming  language.  This  language-specific  data  type  to  refer  to  objects  is  often  an  opaque 
(hidden)  pointer.  The  client  then  passes  that  object  reference  to  the  stub  routines  to  initiate  an 
invocation(27). 


Figure  3.11  The  CORBA  Client  Architecture 


Clients  generally  see  objects  and  ORB  interfaces  through  the  perspective  of  a  GUI  and  lan¬ 
guage  mapping.  Clients  have  no  knowledge  of  the  implementation  of  the  object,  which  object 
adapter  is  used  by  the  implementation,  or  which  ORB  is  used  to  access  it.  The  client  may  only  see 
drop  down  menus  which  allow  a  selection  of  resident  object  references  (and  stubs)  to  be  chosen.  In 
simulation  and  modeling  software  this  is  very  common.  Only  after  the  modeler  has  developed  the 
system  model  is  the  simulation  code  generated,  compiled,  and  run  (see  Figures  3.12  and  3.13). 
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Figure  3.12  Example  of  a  Client  GUI  to  Select  Objects  for  Simulation 


Figure  3.13  Filling  in  the  Parameters  for  the  Operations  to  be  Performed 
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3.1.2  Processing  the  Request.  The  Object  Request  Broker  (ORB)  receives  the  request 
from  the  client  through  the  stubs  or  the  Dynamic  Invocation  Interface  (DII)  (Figure  3.14).  The 
stubs  have  access  to  the  object  reference  representation  and  interact  with  the  ORB  to  perform  the 
invocations.  The  stubs  make  calls  on  the  rest  of  the  ORB  using  interfaces  that  are  private  to,  and 
presumably  optimized  for,  the  particular  ORB  Core.  The  ORB  core  provides  the  basic  services 
of  control,  representation  of  objects  and  communication  of  requests.  The  operations  of  the  ORB, 
which  serve  as  an  interface  between  the  client’s  request  and  implementation  of  the  requested  object 
are: 


•  Operations  that  are  the  same  for  all  ORB  implementations 

•  Operations  that  are  specific  to  particular  types  of  objects 

•  Operations  that  are  specific  to  particular  styles  of  object  implementation 
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Figure  3.14  The  CORBA  ORB  Architecture 


An  interface  is  also  available  that  allows  the  dynamic  construction  of  object  invocations,  that 
is,  rather  than  calling  a  stub  routine  that  is  specific  to  a  particular  operation  on  a  particular  object, 
a  client  may  obtain  the  information  required  for  an  object  reference  from  an  Interface  Repository. 
The  Interface  Repository  is  a  service  that  provides  persistent  objects  that  represent  the  Interface 
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Definition  Language  (IDL)  information  in  a  form  available  at  runtime.  In  addition  to  its  role 
in  the  functioning  of  the  ORB,  the  Interface  Repository  is  a  common  place  to  store  additional 
information  associated  with  interfaces  to  ORB  objects.  For  example,  libraries  of  stubs  or  skeletons 
and  routines  that  can  format  or  browse  particular  kinds  of  objects  might  be  associated  with  the 
Interface  Repository.  This  provides  the  client  with  the  ability  to  search  for  a  simulation  object  and 
include  its  object  reference  in  the  simulation  model(27). 

The  operations  that  are  the  same  for  all  ORB  implementations  are  sent  through  the  ORB 
Interface.  These  operations  include  converting  the  object  reference  to  a  string  for  storage,  duplicat¬ 
ing  and  releasing  copies  of  object  references  to  clients  and  implementations,  equivalence  checking 
and  object  reference  identity (27). 

There  are  a  wide  variety  of  ORB  implementations  possible  within  the  CORBA.  The  imple¬ 
mentations  which  best  support  distributed  simulations  are  the  Server-based  ORB  and  the  Library- 
based  ORB.  The  Server-based  ORB  centralizes  the  management  of  the  ORB  and  all  clients  and 
implementations  can  communicate  with  one  or  more  servers  whose  job  it  is  to  route  requests  from 
clients  to  implementations.  In  some  cases,  where  the  objects  are  “light-weight”  with  regards  to  pro¬ 
cessing  and  storage,  and  their  implementations  can  be  shared,  the  implementation  might  actually 
be  in  a  library.  In  this  case,  the  stubs  could  be  the  actual  methods.  For  example,  the  client  could 
request  the  OE254  simulation,  which  would  request  information  from  the  relational  database  and 
return  results  to  the  client.  This  is  a  Server-based  ORB.  Or  the  client  could  run  the  simulation  as 
a  resident  program,  which  invokes  objects  to  access  the  relational  database(s).  This  assumes  that 
the  client’s  privileges  allow  access  to  the  data  for  the  objects  and  that  the  implementation  trusts 
the  client  not  to  damage  the  data  in  the  relational  database(27). 

The  ORB  also  provides  interoperability  to  other  ORBs  through  the  General  Inter-ORB  Pro¬ 
tocol  (GIOP)  and  Environment- Specific  Inter-ORB  Protocols  (ESIOP).  The  Internet  Inter-ORB 
Protocol  (HOP)  specifies  how  GIOP  messages  are  exchanged  using  TCP/IP  connections.  The  DCE 
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ESIOP  specifies  how  CORBA  ORBs  communicate  with  The  Open  Group’s  Distributed  Computing 
Environment  (DCE). 

3.1.3  Accessing  the  object/data.  The  ORB  determines  if  the  object  reference  is  imple¬ 
mented  through  another  ORB  or  not.  If  the  object  is  implemented  locally,  the  object  adapter 
performs  the  management  functions  for  the  object  implementation.  The  Basic  Object  Adapter 
(BOA)  supports  convenient  interfaces  for  generating  object  references,  registering  implementations 
that  consist  of  one  or  more  programs,  activating  implementations,  and  authenticating  requests.  It 
also  provides  a  limited  amount  of  persistent  storage  for  objects  that  can  be  used  for  connecting  to 
a  larger  or  more  general  storage  facility,  for  storing  access  control  information,  or  other  purposes. 

The  Object-Oriented  Database  Adapter  performs  the  task  of  accessing  the  ODBMS  where 
the  OE254_Path  object  is  stored  and  passing  any  control  or  authentication  information  required 
by  the  DBMS.  During  the  execution  of  the  antenna  object,  the  object  adapter  is  responsible  for 
generating  object  references  and  passing  them  to  the  ORB  if  other  objects  are  requested  by  the 
antenna  object.  The  object  adapter  also  informs  the  ORB  when  execution  is  complete,  so  the  ORB 
can  pass  control  back  to  the  client  with  the  results(27). 

For  a  particular  language  mapping,  and  depending  on  the  object  adapter,  there  will  be  an 
interface  to  the  methods  that  implement  each  type  of  object.  There  is  also  a  Dynamic  Skeleton 
Interface  (DSI)  which  is  the  server  side  analogue  to  the  client  side  DII.  The  DSI  is  a  way  to  deliver 
requests  from  an  ORB  to  an  object  implementation  that  does  not  have  compile-time  knowledge  of 
the  type  of  the  object  it  is  requesting. 

3.7.4  Implementing  the  Object  The  OE254JPATH  object  is  implemented  as  an  executable 
module  or  by  a  file  server  integrated  with  the  DMBS(19)  (Figure  3.15).  The  implementation  is 
transparent  to  the  client  and  distributed  processing  is  supported  easily  in  large  simulations  through 
the  distributed  database  storage  of  simulation  objects.  Control  is  maintained  by  the  ORB(s)  and 
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Figure  3.15  The  CORBA  Object  Implementation  Architecture 


DBMS  until  all  requested  objects  have  been  executed.  When  execution  is  complete,  the  results  are 
returned  to  the  object  adapter  and  any  locks  are  removed. 


3.7.5  Returning  Results  to  the  Simulation.  Results  are  returned  to  the  client  by  reversing 
the  process  by  which  the  request  was  made.  The  results  are  provided  to  the  ORB  by  the  object 
adapter.  The  stubs  provide  the  language  mapping  to  provide  the  results  to  the  client.  Regardless  of 
what  language  the  object  was  implemented  in  or  what  operating  system  the  client  is  using,  appro¬ 
priate  implementations  of  the  CORBA  architecture  allow  distributed  processing  and  heterogeneous 
distributed  database  access  over  possibly  several  operating  systems  in  the  process. 


3.8  Summary 

Objective  1-1  of  the  DoD  Modeling  &  Simulation  Master  Plan  states(28): 

•  Establish  a  common  high-level  simulation  architecture  to  facilitate  the  interop¬ 
erability  of  all  types  of  models  and  simulations  among  themselves  and  with  C4I 
systems,  as  well  as  to  facilitate  the  reuse  of  M&S  components. 

-  Simulations  developed  for  particular  DoD  Components  or  Functional  Areas 
must  conform  to  the  High  Level  Architecture. 

-  Further  definition  and  detailed  implementation  of  specific  simulation  system 
architectures  remain  the  responsibility  of  the  developing  Component. 
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The  CORBA  distributed  simulation  architecture  described  in  this  chapter,  fully  supports  the 
objective  stated  above.  The  mapping  of  programming  languages  to  OMG  IDL  facilitates  inter¬ 
operability  of  all  types  of  models  and  simulations.  Additionally,  the  standardized  development  of 
models  using  the  IDEF  method  provides  a  “paper  trail”  process  to  approve  the  further  development 
of  simulation  objects  for  use  in  the  distributed  network.  All  objects  of  the  same  type  would  be 
required  to  provide  similar  in /out  parameters,  or  the  interface  between  specific  simulations  would 
be  clearly  defined  and  provided  as  a  stub,  skeleton  and/or  object  adapter.  Simulation  objects  are 
reusable  by  referencing  the  object  during  simulation  development  and  their  code  can  be  copied  or 
ported  for  local  use  by  using  a  unique  OID  naming  system. 

Each  Service  Component  can  maintain  a  federated  interface  and  implementation  repository 
for  the  simulation  objects  they  maintain.  These  repositories  can  be  further  federated  to  organi¬ 
zations  responsible  for  specific  C4I  systems.  For  example,  within  the  U.S.  Army,  Fort  Gordon 
would  maintain  communications  repositories  and  Fort  Huachuca  would  maintain  the  repository  for 
intelligence  systems. 
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IV.  Analysis 


4.1  Introduction 

The  first  chapter  presents  a  brief  historical  background  of  the  problems  faced  by  simulators  of 
C4I  systems,  and  the  exact  problem  to  be  solved  is  stated.  The  second  chapter  presents  background 
material  essential  to  understanding  the  approach  Chapter  Three  presents.  This  chapter  presents 
an  analysis  of  the  methodology  and  determines  which  goals  were  achieved  and  which  were  not. 

4.2  Background 

In  1991,  the  Joint  Analysis  Directorate  of  the  Joint  Chiefs  of  Staff  cataloged  over  700  simula¬ 
tions,  war  games,  exercises,  and  models  in  general  use  throughout  the  U.S  Department  of  Defense, 
as  well  as  in  Australia,  Canada,  England,  and  Germany.  There  was  almost  no  ability  for  these 
simulations  to  interact  and  no  evidence  was  found  that  communications  availability  and  fragility 
was  included  in  any  of  the  simulations(24). 

Only  in  recent  years,  have  computer  scientists  begun  to  write  interfaces  for  disparate  simu¬ 
lations.  Pratt  and  Johnson’s  work(31)  in  1993  to  interface  the  Janus  Combat  Model  and  DIS  is 
an  example  of  a  simulation  specific  interface.  However,  there  is  no  flexibility  for  handling  objects 
written  in  varying  programming  languages  or  to  take  advantage  of  distributed  processing  across 
the  network.  The  World  Modeler  application  they  developed  only  provided  translation  and  control 
for  Janus  and  DIS.  The  CORE  A  distributed  simulation  would  use  client  stubs  and  server  skeletons 
to  perform  language  translation  to  and  from  OMG  IDL,  as  well  as  providing  network  management 
and  transaction  control. 

In  1995,  the  U.S.  Army  Communications-Electronics  Command  introduced  the  Integrated 
Terrain-Environment-Multipath  Model  to  add  communications  realism  to  simulations  using  ra¬ 
diowave  communications  systems  in  their  models.  A  distributed  simulation  architecture  would 
make  this  program  available  for  inclusion  within  other  client  simulation  applications. 
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J^.S  Summary 


As  stated  in  the  first  chapter,  the  problem  to  be  solved  by  this  thesis  is  to  develop  a  method¬ 
ology  using  a  standardized  modeling  process  which  integrates  the  technical,  operational,  and  situ¬ 
ational  architectures,  and  results  in  a  distributed  simulation  architecture  by  which  current  systems 
can  be  evaluated  and  future  systems  analyzed.  The  proposed  methodology  is  illustrated  in  Figure 
4.1,  and  is  described  below. 


Decomposition  of  Scenario  Synthesis  of  Objects  Gateway  for  Remote 

into  the  TA.  OA,  and  SA.  and  Database  Records  Accaas  and  Processing 


Figure  4.1  Developing  the  Model,  Simulation  Object, and  Distributed  Simulation  Network 


An  antenna,  the  OE-254()/GRC,  was  modeled  using  IDEF  modeling  methods  to  describe 
the  operational  architecture  of  the  antenna  given  a  common  scenario.  By  including  the  technical 
architecture  constraints  in  the  IDEF  models,  these  architectures  were  integrated  to  describe  the 
system  architecture.  This  standardized  process  provides  the  foundation  for  developing  the  object- 
oriented  code  for  an  executable  simulation  object.  The  development  of  the  object-oriented  code 
could  be  further  mapped  using  the  IDEF4  object-oriented  design  method  not  discussed  in  this 
thesis.  A  brief  overview  of  IDEF4  by  Knowledge  Based  Systems,  Inc.  is  provided  in  Appendix  D. 

The  persistent  data  describing  the  OE-254()/GRC  antenna  from  the  IDEFIX  model  is  then 
stored  in  a  relational  database.  Embedded  SQL  in  the  executable  simulation  object  is  used  to  apply 
the  technical  constraints.  Other  objects  could  be  embedded  with  the  antenna  object,  or  the  antenna 
object  could  be  embedded  in  a  larger  communication  system.  Embedding  objects  only  requires  the 
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CORBA  object  reference  as  a  pointer  within  the  host  program  to  invoke  and  implement  the  object. 
The  storage  of  the  simulation  object  using  an  unique  OID  in  an  ODBMS  was  then  discussed. 

Finally,  an  approach  to  achieve  a  fully  distributed  simulation  architecture  using  the  CORBA 
was  conceptually  provided  by  stepping  through  each  of  the  component  blocks.  The  ability  to  access 
heterogeneous  distributed  databases  and  perform  distributed  processes  was  discussed  as  part  of  the 
capabilities,  as  well  as  support  for  portability  and  reuse  of  simulations  and  interoperability  across 
operating  systems  and  programming  languages. 

J^.J^  Review  of  the  Results 

The  value  of  this  research  is  the  feasibility  of  implementing  the  methodology  described  in 
Chapter  3,  and  the  integration  of  current  modeling  techniques  with  emerging  distributed  object 
technology.  The  results  of  this  research  are  described  below: 

•  The  modeling  standardization  process  proposed  in  the  research  uses  the  Reverse  Engineering 
for  Data  Integration  and  Sharing  (REDIS)  Methodology  currently  incorporated  in  the  DMSO 
Modeling  and  Simulation  Resource  Repository  (MSRR)  standards.  REDIS  provides  a  solution 
to  the  lack  of  common  or  standard  data  definitions  in  the  M&S  community. 

•  The  IDEFO  modeling  method  is  used  to  describe  the  behavior  of  the  simulation  object,  its 
functions,  methods  and  constraints.  The  IDEFO  model  clearly  defines  the  input  parameters 
and  output  parameters  required  by  the  operational  architecture  to  simulate  the  given  real- 
world  scenario.  The  IDEFO  and  IDEFIX  (ER)  models  provide  the  historical  documentation 
necessary  to  validate  the  model  of  the  system  to  be  simulated.  The  advantage  is  once  the 
model  has  been  validated,  it  can  be  reused  by  others  in  the  M&S  community  without  the 
time  and  expense  of  re-validating  the  model. 

•  The  REDIS  ER  product  can  then  be  used  to  define  a  relational  database  to  store  and  man¬ 
age  data  for  the  real  world  objects  to  be  simulated.  The  relational  model  provides  a  strong 
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foundation  for  the  definition  and  management  of  the  persistent  data,  which  is  not  available 
in  current  object  models.  This  moves  the  information  from  the  bookshelf  into  a  standardized 
format  which  can  be  easily  accessed  and  reused.  By  incorporating  the  data  in  the  simulation 
object  programming  language  through  embedded  SQL,  the  data  comes  alive  in  the  simulation. 
The  data  is  no  longer  just  reference  material,  but  is  put  to  use  validating  input  parameters, 
providing  output  parameters  to  other  objects,  and  enforcing  technical  constraints.  The  inte¬ 
gration  of  relational  and  object-oriented  modeling  allows  us  to  take  advantage  of  the  strengths 
in  each  model  while  avoiding  some  of  the  weaknesses. 

•  The  development  of  modular  object-oriented  simulation  objects  serves  two  purposes.  Objects 
can  more  realistically  represent  real-world  systems.  Inheritance,  embedding  or  linking  objects 
through  their  methods,  OQL  ,and  ORB  object  references  (pointers),  allow  a  hierarchical  and 
multidimensional  representation  of  the  real-world  scenario.  Additionally,  modular  objects 
can  be  created  at  the  fidelity  required  by  a  simulation  and  reused  as  components  by  other 
simulations. 

•  By  placing  the  simulation  objects  in  an  object-oriented  database  and  using  a  CORBA  com¬ 
pliant  ORB,  the  distributed  simulation  network  allows  simulation  clients  to  find  and  reference 
simulation  objects  through  the  Interface  Repository.  The  ORB  provides  the  means  to  man¬ 
age  network  connections  and  processing  resources  for  the  distributed  processing  of  multiple 
objects  in  a  simulation,  or  to  allow  the  client  to  port  simulation  objects  to  a  local  processor. 
Simulation  objects  can  then  be  reused  in  many  simulation  applications.  In  the  distributed 
processing  implementation,  the  client  references  the  objects  used  by  the  simulation  without 
regard  to  the  programming  language  the  object  or  application  uses  or  the  operating  plat¬ 
form  capabilities  of  the  client.  The  client  simply  references  the  simulation  object(s)  using  the 
information  provided  by  the  interface  repository  and  receives  the  results  from  the  ORB. 
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•  Additionally,  the  combination  of  emerging  database  and  Internet  technologies  into  a  unique 
infrastructure  for  distributed  simulation  is  realistic.  The  CORBA  is  an  industry  standard 
developed  by  the  OMG  consortium.  It  is  supported  by  the  Object  Management  Database 
Group  (OMDG)  consortium  and  many  applications  using  CORBA  compliant  ORBs  are  cur¬ 
rently  being  demonstrated,  or  are  in  use  today(36).  Also,  many  database  software  companies 
are  moving  to  make  their  DBMSs  CORBA  and  Internet  accessible(39).  The  framework  rec¬ 
ommended  in  the  methodology  is  achievable  using  commercially  developed  products  such  as; 
Logic  Works  ERWin  and  BPWin;  KBSI AIOWIN,  SmartER,  and  ProSim&trade;  Oracle  7  Re¬ 
lational  Database;  Object  Design’s  ObjectStore;  and  DEC’s  ObjectBroker,  HP’s  ORB  Plus, 
or  lONA’s  Orbix.  This  is  not  a  complete  listing  of  all  the  products  available  which  could 
be  used  to  implement  the  methodology,  nor  is  it  an  endorsement  of  any  product.  However, 
it  is  included  to  support  the  feasibility  of  implementing  the  proposed  distributed  simulation 
framework. 

4-5  Comparison  with  Other  Distributed  Simulation  Architectures 

4.5.1  Common  Operational  Modeling,  Planning,  and  Simulation  Strategy  (COMPASS). 
COMPASS  Technology  is  a  middleware  application  which  interfaces  existing  M&S  programs  by 
formatting  data  into  Distributed  Interactive  Simulation  (DIS)  Protocol  Data  Units  (PDU)(1).  DIS 
protocols  can  be  exchanged  with  any  other  program  that  implements  the  DIS  protocol  interface 
standard  over  a  network. 

At  the  moment,  DIS  is  working  well.  However,  DIS  captures  entity  interactions  in  a  flat  (non- 
hierarchical  manner).  Since  DIS  PDU’s  cannot  inherit  from  each  other,  interactions  among  entities 
must  be  individually  developed.  This  means  that  every  entity  must  have  a  set  of  PDU’s  developed 
for  every  other  entity  with  which  it  must  interact.  DIS  also  suffers  from  a  lack  of  abstraction.  Every 
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entity  in  DIS  exists  independently  and  equally.  This  means  that  DIS  fails  to  exploit  hierarchical 
structures  and  commonalities  which  exist  among  varying  real-world  entities(30). 

The  proposed  methodology  exploits  the  object-oriented  model  and  uses  distributed  object 
processing,  database  management  and  the  CORBA  to  build  the  distributed  simulation  network. 
Object-oriented  design  allows  the  structured  characterization  of  entities  based  on  the  hierarchical 
relationships  of  real-world  systems,  and  inheritance  from  higher  (base)  classes  to  lower  (sub)  classes 
derived  from  the  base  classes.  The  object-oriented  model  also  allows  the  encapsulation  of  data,  and 
linking  (or  embedding)  of  objects,  to  represent  complex  behaviors,  instead  of  crafting  an  entirely 
new  DIS  PDU.  In  fact,  DIS  itself  could  be  encapsulated  in  an  object  using  this  paradigm. 

COMPASS  is  successful  in  providing  interactivity  between  current  C4I  systems  using  the  DIS 
PDU  and  the  Internet.  However,  the  proposed  methodology  provides: 

•  the  scalability  of  object-oriented  design  not  found  in  DIS  PDU  based  simulation  systems, 

•  scalar  data  definition  and  management  using  the  relational  model, 

•  data  independence  by  integrating  the  two, 

•  and  interoperability  with  platform  and  programming  language  independence. 

4.5,2  Joint  Modeling  and  Simulation  System  (J-MASS).  Although  the  methodology 

presented  was  developed  independent  of  any  knowledge  of  J-MASS,  the  simulation  architectures 
are  strikingly  similar.  The  major  efforts  of  J-MASS  have  been(23): 

•  Development  of  a  common  digital  simulation  architecture 

•  Definition  of  standard  interfaces 

•  Application  of  commercial  standards  (e.g.,  POSIX,  MOTIF,  X-Windows,  CORBA) 

•  Visual  Computer  Assisted  Support  Environment  (CASE)  tool  environment 

•  Application  of  modeling  and  simulation  to  the  acquisition  lifecycle 
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The  J-MASS  is  currently  a  software  application  that  runs  on  SUN  and  SGI  machines.  It  uses 
an  ODBMS  for  object  storage  and  does  not  use  relational  databases.  The  architecture  proposed  in 
the  methodology  integrates  relational  and  object-oriented  databases  to  strengthen  the  underlying 
model  and  simulation  repositories.  Also,  J-MASS  does  not  use  a  commercially  standard  CORE  A, 
but  has  developed  a  unique  CORBA-like  architecture  called  the  Simulation  Support  Environment 
(SSE)  Interconnect  Backplane  (IBP).  Since  J-MASS  states  individual  organizations  would  solicit 
solutions  from  the  commercial  marketplace  for  unique  requirements  and  capabilities,  these  products 
would  have  to  be  created  or  existing  products  made  “J-MASS  compliant”.  The  added  J-MASS 
compliance  means  added  cost  to  the  client.  Finally,  J-MASS  does  not  specify  a  process  for  de¬ 
veloping  DoD  standardized  models  of  real-world  systems,  as  the  proposed  methodology  does  with 
the  technical,  operational,  and  system  architectures,  and  IDEF  modeling  methods.  J-MASS  does 
require  objects  representing  those  real-world  systems  to  be  structured  compliant  with  the  J-MASS 
Software  Structural  Model  (SSM).  The  SSM  enforces  software  structure  and  interface  standards  for 
all  levels  of  object  decomposition  to  ensure  any  object  in  the  J-MASS  system  can  be  syntactically 
“connected”  with  any  other  objects  in  the  system  with  guaranteed  success. 

Since  J-MASS  is  current  technology  developed  by  the  U.S.  Air  Force,  the  ODISC4  should  use 
this  system  as  a  basis  for  developing  a  CORBA  compliant  distributed  simulation  architecture,  en¬ 
forcing  the  standardize  model  development  process,  and  employing  the  multi- database  architecture 
proposed  in  the  methodology. 

^.6  Goals  Achieved 

The  goals  achieved  by  the  proposed  methodology  are: 

•  a  process  for  standardization  of  C4I  data  models, 

•  integration  of  the  technical  and  operational  architectures  into  the  simulation, 

•  historical  records  of  data  collection  and  process  description,  and 
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•  distributed  database  access  and  processing  using  CORE  A. 

COREA  supports  heterogeneous  distributed  systems  incorporating  object-oriented  databases, 
relational  databases,  operating  systems  independence,  and  programming  language  independence. 
As  a  result,  requirements  for  portability,  re-usability  and  interoperability  described  in  the  DMSO 
HLA  can  be  achieved  using  this  architecture. 

4.,7  Goals  Not  Achieved 

The  original  intent  of  this  research  was  to  implement  a  distributed  simulation  network  using  a 
COREA  compliant  ORE  and  the  modeling  standardization,  object  development,  and  database  tech¬ 
niques  described  by  the  methodology.  Additionally,  the  simulation  to  be  run  over  the  distributed 
network  was  to  include  time-dependent  weather  characteristics  found  in  a  desert  environment.  The 
research  conducted  to  include  weather  in  a  C4I  simulation  utilizing  radiowave  communications  is 
included  in  Appendix  C.  This  goal  proved  too  ambitious  given  the  time  and  resources  required 
to  complete  such  a  goal  However,  the  need  for  a  clear  methodology  to  construct  such  a  network 
motivated  the  research  and  publication  of  this  work. 
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V,  Recommended  Continuing  Research 


5.1  Introduction 

The  first  chapter  presents  a  brief  overview  of  the  problems  faced  by  simulators  of  C4I  systems, 
and  the  problem  addressed  by  this  research  was  stated.  The  second  chapter  presents  background 
material  essential  to  understanding  the  process  and  infrastructure  described  in  Chapter  3.  Chapter 
4  presents  a  brief  summary  of  the  methodology  and  discussion  of  its  availability  and  applicability. 
This  chapter  reviews  the  problem  and  the  answers  provided  by  this  thesis  and  makes  recommen¬ 
dations  for  further  research. 

5.2  Review 

The  development  of  a  multi-database  federated  repository  system,  using  CORBA  to  manage 
the  distributed  simulation  network  combines  the  power  of  state-of-the-art  technologies  with  time 
tested  simulation  applications  and  data  management  techniques.  The  explosive  growth  of  the 
Internet  and  the  enabling  technologies  that  have  grown  with  it,  provide  the  simulation  community 
with  an  opportunity  to  achieve  greater  interoperability,  re-usability  and  portability.  The  framework 
provided  by  this  research  sets  the  foundation  for  taking  greater  advantage  of  this  technology. 

5.3  Recommended  Research 

The  recommended  research  is  directed  at  the  steps  necessary  to  implement  the  distributed 
simulation  network  described  in  this  research.  These  are  listed  as  areas  of  recommended  research. 

1.  Expand  the  model  standardization  process  by  combining  IDEF2  (Simulation  Model  Design) 
and  IDEF4  (Object-oriented  Design)  methods  with  the  IDEFO  and  IDEFIX  methods  de¬ 
scribed  in  Chapter  2. 

2,  Develop  a  client  GUI  Modeling  and  Simulation  application  using  CORBA  object  references. 
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3.  Create  and  populate  an  Object-Oriented  database  and  Relational  database  and  use  the 
CORBA  gateway  architecture  as  a  multi-database  management  system(20). 

4.  Integrate  a  file  server  with  the  multi-database  system  to  perform  distributed  processing, 

5.  Create  a  simulation  of  simulations  invoking  objects  over  multiple  ORBs. 

6.  Develop  a  geographic  mapping  of  the  distributed  simulation  network  to  optimize  accessibility 
and  object  processing.  The  distributed  capabilities  of  the  recommended  architecture  require 
management  of  resources  to  optimize  the  network.  Component  models  and  simulations  can 
be  developed  and  stored  at  facilities  which  have  responsibility  for  technical  and  doctrinal 
development  of  the  systems.  Not  discussed  in  this  thesis  is  the  structure  of  a  federated 
model  and  simulation  repository  for  the  Department  of  the  Army.  For  example,  Fort  Gordon 
would  administer  the  CORBA  ORB  server,  relational  databases,  object-oriented  databases 
and  federated  interface  repository  for  U.S.  Army  communications  systems.  The  Global  Inter¬ 
face  Repository  and  approval  authority  for  including  models  and  simulations  in  the  federated 
simulation  repository  would  be  controlled  by  a  Defense  Department  agency. 
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Appendix  A,  IDEFIX  Antenna  Model 


The  following  diagrams  show  the  entity  relationship  model  of  an  antenna,  as  reverse  engi¬ 
neered  by  the  Joint  Database  Element,  Fort  Huachuca,  and  schema  for  the  entities  required  in  this 
thesis. 


A-1 


Electromagnetic  Environment  Subject  Area  Information  Model 

Version  2.0  ANTENNA-TYPE _ 

Created:  August  31 , 1995  f ANTENNA-TYPE  Identifier.Materiel  Identifier  (FK) 

Updated:  September  24, 1 995  - "— 

ANTENNA-TYPE  Use  Name 


<D 

■o 


<D 

E 

CO 

Z 

CD 

XD 

O 


CD 

E 

CO 

z 

XD 
CD 
(D 
CD  LX. 

E  c 

CO  o 
2:  CO 

Ee 

CO 

o  c 
CO  CO 


CD 

CO 

cc 


CO 

c:  cO  o 

CD  .o  c 

p:  ^  iS 

o  o. 

Z  <  Q 
LU  LU  LU 
Q.  CL  □. 

"Z.'Z'Z. 


LU  LU  LU  LU  LU 
h-  h-  h- 


O 

2  -i 

O  CO 

9:  E 


CD 

E 

CO 


o 

‘co 

CD 

E 

b 


LU  LU 
□l  0- 

<  < 


.i 

>  X  X 
CO  CO 

Q  S  S 
LU  LU  LU 
CL  CL  Q. 

<  <  < 


LU  LU 
□.  CL 


CO  J— 

o 

CO 


8 


o  □. 

LU  LU 
□.  CL 


"co  ^  'co 
CC  c 

O  S'  I 
Sob 
S-  cr  c 
9  o 
it  ll  □- 

cn  CD  TS 

IE’S 

l|S 

li^l 

LU  LU  LU 
CL  CL  CL 

<  <  < 


CO 

QC 

S' 


5 

o 

a. 

*o 

CD 

oc 

.i 

8 


C  o  E  E 


2  iE 


58  S  o 


O 


CL  CL  CL  CL 


'Z.'Z.:2L'Z.'Z.’Z.'Z.-^'Z.'2L'Z.’Z. 

I  III  III  III  III  III  I  H  III  Hi  [  l-l 


<<<<<<<<<<<<<<<<<<< 


DC 

LU 

< 

'Z. 

z 

LU 

h- 

z 

<:  CO 

O  *5=: 

E 

CO 

1  s. 

i  I  O 


CO 

< 


< 

DC 

O 

LU 


CL 

Z 

z 

LU 

I- 

z 

< 


F— ^ 

C  c 

s?  0  .2 

a  c 

tz  ®  2 

.0  E  .i 

■5  Q  Q 

|Sf 

S 

CO  E  1 

i  E  E 

c 

CD 

<  s  s 

h“  ^  h— 

CO 

CO  CO 

< 

<  <  < 

^ 

LI _ 1 

Jj  -1j  JLi 

<  <  < 

fe  DC 

DC  DC  DC 

E  0 

0  a  CD 

LU 

LU  UJ  LU 

Q> 

h-  h“ 

"ZZ-Z 

LU  LU 

1  1  I 

LU  LU  LU 

□.  CL 

Dl  CL  CL 

P7 

fr  ^7  »T 

<  < 

<:  <  < 

zzz 

•Z.ZZ 

LU  LU 

LU  LU  LU 

1-  1- 

1-  K-  h- 

z  z 

zzz 

<  < 

\ _ _ ! 

<  <  <  / 

M 


i 


EQUIPMENT _ 

f  Materiel  Identifier  ^ - ,  TRANSMISSION-RECEPTION-EQUIPMENT-TYPE 


O 

to 

C\J 


o 

T~* 

in 

CO 


ACTIVE-NONLINEAR-COUPLING-TYPE 
'  LEAD-IN-COMPONENT  Identifier  (FK) 


COUPLER _ 

1eAD-IN-COMPONENT  Identifier  (FK) 

COUPLER  Forward  Loss  Rate 
COUPLER  Reverse  Loss  Rate 


O 

T~ 


o 

lO 

CM 

cm“ 


E  Identifier  (FK) _ 

;-TYPE  Tip  Array  Axis  Angle 


ACTIVE-NONLINEAR-COUPLING-TYPE  Crossmodulation  Conversion  Loss  Quantity 
ACTIVE-NONLINEAR-COUPLING-TYPE  Crossmodulation  Conversion  Loss  Standard  Deviation  Quantity 
ACTIVE-NONLINEAR-COUPLING-TYPE  Desensitization  Coefficient  Rate 
ACTIVE-NONLINEAR-COUPLING-TYPE  Desensitization  Power  Breakpoint  Quantity 
ACTIVE-NONLINEAR-COUPLING-TYPE  First  Power  Breakpoint  Crossmodulation  Power  Region  Quantity 


O 

in 

CO 

csT 


justability  Code 
ed  Vertical  Quantity 
limum  Adjustable  Sector  Quantity 
jcimum  Adjustable  Sector  Quantity 


ANTENNA-RF-MULTIPLEXER  Maximum  Passband  Rate  I  splits  frequency  into 
ANTENNA-RF-MULTIPLEXER  Recovery  Period  Quantity  I 


2,4  /5, 10 


:>  o  o  o  o  o 
5  Q  Q  Q  Q  Q 
D  O  O  O  O  O 
c  cc  oc  cr  cc  cr 

U  LU  UJ  LU  LU  LU 
LQ-Q.O.CLQ- 

15  CD  6  6  O  6 

332322 


_J  CO  i= 
CD  <D  <D 


LU  LU  LU 
Q-  0-  0- 

LU  LU  LU 

DC  DC  gc 

CD  CD  CD 

z  z  z 

222 

I  I  I 

CD  CD  CD 
^  ^  ^ 
Q.  Q.  O. 

232 

CO  CO  CO 


i  II 

C  Q  Q 


^  f 

U-  < 


O) 

_  c: 

< 

Ll_  X 
CD 


d 

C 

o 

'co 

c 

CD 

E 

O 

b 

CO 

,  • 

c: 

^  CD 

O) 

CD 

.i  O) 

'CD 

cd 

—  LU  LU  I 
L  Q_  Q_  I 

1 

_  QC  DC  I 

2  O  O  < 

<  X  X  ; 


LU  CL  CL  X  Q.  Q. 

^  mil 

%  CD  CD  6  CD  CD 
2  X  2  X  X  X 
LU  CL  CL  CL  X  CL 

t  O  O  O  O  O 

!  2  _1  _l  _l  ^  ^ 

i  <  tn  tf>  Kf><r> 


SLOTTED-WAVEGUIDE-TYPE 
'antenna-type  Identifier  (FK) 


UJ 

a. 


< 

O 

o 

LU 

CC 

Q 


a> 


CO 

3 

O 

E 

CO 

CD 

CD 

CO 


§  *$< 
c  a> 

iS  *“ 

^  CD 
1  = 
^  .1 


CD 

h" 

^  J9? 

=  O) 
-Q  c 
CO  < 

CO 


CD 


o 


e  E 


rS  ^  ."ti  .■ti 

o  ^  55  55 


^  CO 
T3  O 

«  s  °- 

i  §-i 

E  ^  CD 
CO  ^  CQ 
LU  UJ  LU 

Q_  Q_  □_ 


M 

< 

CD 

O) 

CO 

I 


CD  O 
LU  LU 
CL  CL 

<  < 


E  E 

S 

^  CD 
CO 

E  i5 

O  CD 

CD  cr 

LU  LU 
CL  CL 


CD  (i> 

E’  o) 
<  < 
1  o 

^  S 

LU  LU 
CD  ■}=; 

.55 

rn  CO 

g  g, 
O  O 
O  CD 
LU  LU 
CL  CL 


•ii  o  s; 

^  ^  c 

UJ  LU  O 

S  'oj 

.2>-o)  o 

CO  Q- 

^  £ 

/S  o  ^ 
CD  ^  o 

E  e 

=3 


s  ;il 

s  :s  oc 

LU  LU  LU 
CL  CL  CL 


III  III  III  III  HI  III  I  H  Hi  UJ  LU  UJ  LU 


Z  IZ 
<  < 


z  z  z  z 

<<:<<: 


<<<<<< 


<  <^  < 

-j  _j  — I  — I 

<  <  <  <  < 


CO 


CD 


E 

CO 

CD 

.O 

C 

CO 


^  'rrt 


CD 

CO 

cr 

CD 

O 

CD 

"5 

CO 

CO 


cr 

LU  LU  LU  LU 
CL  CL  CL  CL 


i’i 

^  .i 

CO 


III  III  III  III  III  III  til  III  111 

gc  gc  gc  DC  gc  DC  QC 

CD  Q  CD  Ci  Q  Q  CD 


gc  gc  gc  gc  gc  gc 

CD  Q  CD  O  CD  Q 


o 

}— 

DC 

LU 

> 


2  z  z 


<  <  < 


QQQQQQQQQQQQQQ2Q 


LU  LU  LU  LU 
‘  DC  DC  DC 


CD  O  O 


1 

O 

§ 

o 


o 

lO 

CM 

CO 


HFI  inAI  -TYPF 


ANTENNA-POLARIZATION _ 

ANTENNA-POLARIZATION  Identifier 
ANTENNA-TYPE  Identifier  (FK) 

ANTENNA-POLARIZATION  Type  Code 


SLOTTED-WAVEGUIDE-Pl'PE  WaveGuide  Quantity  I  ANTENNA-TYPE  Idantifiar  (FK) 

SLOTTED-WAVEGUIDE-TYPEWaveGuide  Slot  Quantity  I  - ^ - 

SLOTTED-WAVEGUIDE-TYPE  Slot  Width  Dimension  I  COLLINEAR-ARRAY-TYPE  Segment  Quantity 

SLOTTED-WAVEGUIDE-TYPE  Slot  Height  Dimension  I - 1  COLLINEAR-ARRAY-TYPE  Segment  Length  Quantity 

SLOTTED-WAVEGUIDE-TYPE  Slot  Spacing  Dimension  I  COLLINEAR-ARRAY-TYPE  Segment  Spacing  Quantity 


CO 

c 

c: 

s 

c 

< 


o 

O 


LU  ! 
1—  1 

Z  g  1 

o  o 

< 

o  o  j 

CL 

< 

GC 

CL. 

CO 

I 

< 

Q 


LU 

X 

o 

cc 

< 


O)  i 

■<  i 

^  B 

LU 

S' 

Q_ 

JIj 

< 

c 

oc 

CD 

2 

Gl 

CO 

LU 

0. 

V- 

1 

< 

:z 

CD 

LU 

z 

LU 

LU 

1— 

O 

az 

l< 

< 

CD 
O)  ^ 

3  E 

<C  CO 

c  z 
O  o 

I  ^ 

•ii 

O  Q 
S  o 

CO  CO 
LU  LU 
CL  CL 

LU  LU 

Q  9 

ZD  ^ 
CD  CD 
LU  LU 

II 

CD  Q 
LU  LU 

CO  CO 


1 


o 

in 


^  Q 
-c 


CD 

*0  CD 


Q.  LU 

I  s 


LU  LU  LU 
XXX 


CD 

•o 

O 


O 


ANTENNA-TYPE-BEAM  Null  Offset  Angle 
ANTENNA-TYPE-BEAM  Null  Supression  Level  Rate 
ANTENNA-TYPE-BEAM  Description  Name 
ANTENNA-TYPE-BEAM  Front  Back  Ratio  Rate 


APERTURE-REPRESENTATION  Type  Code 


>xial  Ratio  Rate 
lajor  Axis  Tilt  Angle 


RHOMBIC-TYPE  Antenna  Type  Identifier 


O 

lO 

LO" 


BEAM-FORMATION-METHOD 
^SCAN-MODE  Identifier  (FK) 


a 

=  *2  S?  Q 


QC  oc  cr 

LU  LU  LU 
Q-  CL  Q_ 

<  <  < 

I  I  I 

Q  O  O 

CC  OC  OC 
CD  OQ  00 
>->->- 
□:  X  X 


CC  CC  CC 
LU  LU  IXI 
Q_  a.  CL 

<<F5 

Q  Q  Q 
CC  CC  CC 
CD  00  00 
>•>->- 
XXX 


yj  00  00  ^  CD 

k  00  I  I  I 

LU  LU  LU  LU 

yj  CL  D-  CL  CL 


LU  X  X 
I—  <  < 

X  o  o 

<  CO  CD 


O)  c: 

3  < 

^ 


•  CD  S  X  X  X  X 

S  LU  LU  O  O  O  O 

^  Q-  CL  p  p  I—  I— 

h  ^  oobo 

O  I—  l—  LU  LU  LU  LU 

yj  <  <  X  X  X  X 

—  X  X  O  Q  Q  Q 


LU  LU  LU  LU 


^g[<<<|<< 


c  <  ■£ 

h  LU  -S 

fi  CO  2 


<  <  <  < 
LU  LU  LU  LU 
ca  CD  CD  CO 


,  C  <!  1— ’  I— 


SCAN-MODE  Identifier  (FK) 
SCAN-COMPONENT  Identifier  (FK) 
ANTENNA-TYPE  Identifier  (FK) _ 

ELECTRONIC-SCAN-TYPE  Scan  Plane  Angle 


ANTENNA-TYPE  Identifier  (FK) _ 

CIRCULAR-APERTURE-TYPE  Diameter  Dimension 
CIRCULAR-APERTURE-TYPE  Amplitude  Distribution  Name 
CIRCULAR-APERTURE-TYPE  Phase  Distribution  Name 


ANTENNA-TYPE  Identifier  (FK) _ 

SCAN-COMPONENT  Scan  Method  Name 
SCAN-COMPONENT  Scan  Plane  Angle 


SCAN-COMPONENT  Identifier  (FK) 

ANTENNA-TYPE  Identifier  (FK) _ 

BEAM-FORMATION-METHOD  Period  Quantity 
BEAM-FORMATION-METHOD  Scan  Unit  Azimuth  Angle 
BEAM-FORMATION-METHOD  Azimuth  Shift  Rate 


SCAN-MODE  Identifier  (FK) 

SCAN-COMPONENT  Identifier  (FK) 

ANTENNA-TYPE  Identifier  (FK) _ 

FREQUENCY-SCAN-TYPE  Beam  Shift  Frequency  Change  Rate 
FREQUENCY-SCAN-TYPE  Total  Frequency  Step  Quantity 


ELECTRONIC-SCAN-TYPE  Beam  Motion  Name 
ELECTRONIC-SCAN-TYPE  Array  Design  Name 
ELECTRONIC-SCAN-TYPE  Tilt  Angle 
ELECTRONIC-SCAN-TYPE  Array  Face  Quantity 
ELECTRONIC-SCAN-TYPE  Face  Coverage  Angle 


6,2  /5, 10 


SCAN-COMPONENT  Scan  Method  Name 


O 

iO 

CO 

(D 


UJ 

D- 

< 

o 

LU 

h“ 

CO 

< 

CC 

5 


O 

o 

Q 

CC 


^  'nr 

U-  S 

nr  s  ^ 

a>  I _  c 

tz  <D 

z  -o 


O  ^ 

O  < 

V  z 

Z  LU 
<  h- 
O  Z 
CO  < 


CD 

^  o> 
O)  c 

-c:  o 


CD 


CO 


S  s  § 


o 


E  S 


CD 


LU 


CO 


c 

^5  5  m  S 


05  o  a>  o  o 

o5  00  00  1- 


(D 

■O  ^  _ 

O  CO  CO  CO  CO  CO 
O  OC  CC  DC  CC  CD 
LU  LU  LU  LU  LU  LU 
□-  CL  CL  D-  CU  CL 


05 

m  1- 

CO  ^ 

^  s  •■§ 

C  §  ^ 

o02 
^  O  E 
^  a5  S 

CO  CL  CQ 

CO  CO  CO 
CD  CD  CD 
LU  LU  LU 
CL  CL  CL 


>7*  c 

CC 

c:  = 

S  c  c 

o  3  ^ 
■§2  a 
Sic 

CL  CD  CC 
CD 

O  ir 

5  -P  ^ 

i5  ^  CC 
CD  LL  CC 
LU  LU  LL 
CL  CL  a 


<<<<<<<<<<<< 

oooooooooooc 

COCOCOCOCOCOCOCOCOCOCOC^ 
CC  ^  CC  ^  ^  i  i  DC  CC  CC  CC  a 

LULULULULULULULULULULUa 

cococococococococococoa 

<<<<<<<<<<<< 

DCCrcCDCDCDCDCCCDCDCDCa 

<<<<<<<<<<<< 

<<<<<<<<<<<< 

x::EXx^xxxx^3ca 

oooooooooooc 

LULULULULULULULULULULUa 

66000000000c 

Qd^QQC^OQCiQQCiC 

QQQQQSQQQQQS 

xxxxxxxxxxxa 

LULULULULULULULULULULUa 

CLQ_Q_CLO.CLCLQ.Q.CLCLa 


<D 


ANTENNA-TYPE  Identifier  (FK) _ 

TARGET-TRACK-PROGRAM  Switch  Target  Track  Quantity 


PbHiuuiu-tLbu  I  HUNiu-bUAN- 1  YKb  Program  perioa  Limit  uuantity 
PERIODIC-ELECTRONIC-SCAN-TYPE  Beam  Position  Rule  Text 
PERIODIC-ELECTRONIC-SCAN-TYPE  Code 


IT) 


CVJ 


O)  , _  I— 

bz  o> 
z  *0 
c  in  — 

-S  Z  LJJ 

—  o  ^ 

LU  Q-  C 

S  ^  5 
o  o  < 
so? 


<  <  h- 
0  0  2 
CO  CO  < 


Q.  Q.  O. 

2  2  2 
<  <  < 
000 

CO  CO  CO 
_1j 

<  <  < 
000 
222 
000 
000 


c^  a. 

222 
<  <  < 
000 

CO  CO  CO 
Jj  Jj  Jj 
<  <  < 
000 
2  2  2 
000 
000 


<  LJJ  Q-  C 

^  9  ^  > 

CO  O  O  ^ 


Jz  <  <  I— 
O  O  2 


< 

o  . 


O 

CO  t. 


CQCQOQOOGQCDCQCQCDCQCQCQ 

ooooooQQQoqq 


CO  £5  1 

oo.i'. 


<<<<<<<<<<<< 

222222222222 

<<<<<<<<<<<< 

XXXXXXXXXX2X 

000000000000 

UJLiJLUUJUJLJJUJLLILlJLULLILU 


^  2  LU 

—  O  0: 

UJ  Q-  C 


PERIODIC-MECHANICAL-RASTER-SCAN-TYPE  Raster  Scan  Period  Quantity 


7,4/5,  10 


8,2  /5, 10 


MECHANICAL-SECTOR-SCAN-TYPE 


U-  S  .9^ 
'ZT 12  ^ 

tr  a> 
-o 

«=  LU  — 
^  2  UJ 

sgo: 

111  Q.  C 

S  ^  5 

o  o  $ 

?9i 

Z  Z  LU 
<  <  H- 
O  O  Z 
CO  CO  < 


?  <D 

i  E  ><  « 

5  CO  S  3 


*o 
^  O 

■><  CD 

Q>  fz  a. 


C  o  o 

S  -2  E 

CO  CD  o 

CL  cr  o 


o  o  o 

CO  CO  cn 

LU  LU  LU 
CL  Q-  CL 

z  z  z 
<c  <c  <c 
o  o  o 

CO  CO  CO 

GC  cx:  oc 

o  o  o 


O  r-  e 
&  CO  CO 

E  c!5  <D 
2  CO  CD 
^  o  o 

CO  CD  tj 
o  CD  CD 
CO  CO  CO 
LU  LU  LU 
Q-  0-  0- 

z  z  z 
<c  <c  <c 
o  o  o 

CO  CO  CO 

^  ^  ^ 

cc  cc  cc 

o  p  o 


CD 


^  c  TO 

0-1  5 

irz  •«— » 
CD  -O  TD 

t3 

>■»  CD  CD 
LL  CO  CO 
LU  LU  LU 
a.  CL  o. 


<<<<<<<<<<< 

ooooooooooo 

cococococococococococo 

ccccocdrcncEtrcccrccci: 

OOOOOOOOOOO 

o&oooo&^obo 

LULULULULULULULULULULU 

COCOCOCOCOCOCOCOCOCOCO 

<<<<<<<<<<< 

opopppppppp 

zzzzzzzzzzz 

<<<<<<<<<<< 

xzxxzxxzxzx 

ooooooooooo 

LULULULUUJLUUJLULUUJLU 


CD 


LU 

CO 


CO 

<D 

> 

'8 

CO 

c 

CQ 


*0 

c 

cd 


1 


I 

'CD 

O 

Q 

O 

'co 

CO 

o 

Q. 

CO 


cd 

c 

c 

5^ 

c 

Cd 

c 

Cd 

CO 

c3 

Q> 

c 


0 

X 

0 

X 

s- 

C 

o> 

1 

H  1 

■0 

Q 

l^Q 

p 

0 

z  0 

■53 

X 

c 

1 

i , 

o> 

0 

E 

1 

Q 

0 

X 

o°- 

0 

t3 

LU 

0 

Z  ■« 

0 

' 

p 

0-2 

0 

X 

«i  => 

zo 


o 


3  c  ^ 
CO  ^  0’  ;S  w 

Z  _1  Q.  < 
~  -g  0-  >-  X 
0  3  H  o 

.9-0,2  “I 


Z 

LU 

I- 

Z 

< 

CO 

<D 

O 

c 

CD 

ii» 

0) 

X 


o 

'Vm, 

CO 

CD 

X 


X 

LU 

O 

LU 

X 

Z 

o 

CO 

CO 

CO 

z 

< 

X 


CO 

CD 

X 


3 

O 


CO 

CD 

X 


CO 
W-  <L> 
O  X 


4=  VI 

fn  ^ 


Q 

< 

LU 


'=5  Jz 


cr< 

CD 


UJ  ■£ 


Z  CD  — .  , 

LU  £  LU  < 

H  •-  H  ^ 

Z  Z  CO 

<  I  <  g  2 
Ei  Ez5 

Cd  (D  Cd  flv  ^ 

ZDZ^  I 

'<4S  ^  ’h- 

C  C  Cd  4=5  p 

LU  LU  H  <  O 


c 

CD 

■o 

LU 

X  is 

c  0) 

Q<  . 

— 'z  ^ 
b) 

S  ^  5J 

|<Z 

0)  05  £ 
^  ^  £ 
?:.c5? 

c  CD  DC 

■c  O 

XXX 


sf 

c  ^ 
Q  O 

•53 

D-.S^ 
LU  Jn 


CO  .« 
CD  9 

o  ^ 

s  ^ 
0)  0) 

(1)  X 
a>  * 
X  — 


Q  -1 

I  s 

|cr 


.2 

■§ 

o 

c 

p 

t5 

p 

o 

o 

CD 


0 

O 

■> 

<D 

TD 

Cd 


O 

LU 


X 

X 

CO 

0 


0 

E  i 

m  C 
0 


0 


II 

^  o 


9  a 

_|-5=' 
<1>  CT  Hi 

PI 

«  CE  ^ 

T.  in. ^ 

I 

^  c  »2 

C  0  X 

•i  o  ^ 

XXX 


LU 
X 

H  ^ 

•T  0 

<  0  < 

z  o  2 


^3 

S;;,Z 

0  LO 
2  CO 

X  DD 

X  < 

^5 

<  Q 

Z 


S  H 


^  0 

LU  •= 

Z  <D  Z  ^ 

CO 


©« 


2  0 
w  f-  0  cd  ^ 
E;i  Ez5 

Z  Q  Z  S  c 

«Si| 

iSSiSSS 


5o 

:e 

X 

—  0 

0  /5 

0  O 
O  1 

E  ^ 
0 

0  ^ 
X  t3 

1 

’i^ _ 

c 

0 

•O 

X 

0-  ■« 
^  0 
X  ^ 

Q  <  I 

Di  3 
•gm  b) 
S2 

|<Z 

(D  0)  f. 

«.g>® 

I  §5 

XXX 


0 

l=r 

^  CO 

2x 
3  < 

tX 


X 

X 


< 

z 

z 

X 


o 

0 

§ 

0 


0 

0 

I 

z 

0 

^  t- 

ti  O 

<0 


0 


c 

0 

2 

0 

cd  L?? 
o 

Ex 

z  ^ 

LU  £ 

0-  3 

t  - 

ii 

65 

<< 

p 

P 

3I 

EE 


0 

E 

0 


0 

■o 

O 


0  O 

M  2i 

mo 

^•2 
i  td 
S  o 


c 

o 

0 

c 

0 

E 

G 

-  CM 


i2  CD 


0 

CO 

a 

X 

X 


< 

o 


T 


X 


CL 

CL 

c 

< 


0 

0 

E 

0 

z 

2 


< 

z  _ 

Z  0 

ms 

<< 
w  ro 
^  8 
I  E 


0 

E 

0 

z 

O) 

ito 

0 

X 

< 

g 

St 

z^ 


0 

E 

0 


X3 

0 

0 

X 

c 

o 


0 

E 

0 

z 

0 

P-? 


0  DC 

£  < 
5  X 
HO 


X 

X 


X 


0 


0 


B  c 
5  E 


0 

0 

E 

0 

z 

0 


8 

5 

< 

0 

0 

E 

0 


S5  Sd  rys  g3 


ti  o 
<  O 


ts  o 

<  O 


4=5  O 

<0 


c 
E 

_  2 
ts  o 
<  O 


^  5 

X  .2 

>.  0 

<  ^ 

I  2 

Z  0 

lii 


<< 

p 

C  E 
«  0 
^  Z 

2  c 

3  E 

€2 

ts  o 

<  O 


0  >- 

,2  H 


10 

CM 

Ii 

Q  X 
X  O 
X  0 
Q. 
>> 


< 

Z 

z 

X 


<< 

8  w 

ii 
0  <- 
II 

^  o 


1 

X 

1^ 
OT  O 

II 

Si 

2  0) 

x  ts 

.  2 

<  0, 

^  x' 
X  ^ 

5 1 

<  ^ 


X 


0 


0 

0 


0 
Ei 
z| 

3  c 

II 

Id  o 

<0 


o 

c3 


c 

o 


CO 

S 

0) 

If 

■i  o 

uj  2 
Q_  <D 

I- 

< 


LU 


8 

5  i 

CO  ^ 


c 

o 

CO 

c 

CD 

e 

b 


D)^ 

S 

LU  b 

>q 


O) 

*0 

5 

LU 

CL 


!< 

O 


it 

LU  Q 


CO 

0 

E 

0 

z 


|i 

ti  o 
<  O 


0 

p 

«  I 

II 

ti  O 

<  o 


O) 

<< 

p 

if 


II 

^  O 


0 

E 

0 

z 

s. 

>S 

0  S 

■^< 
2i 
qO 
LU 

<:  .2 
z  ts 
z  0 

LU 


a 


z 

< 

CO 

0 

I 


0 

ZJ 

5 


3 

c 

0 

0 

0 

E 

0 

z 

c 

E 

D 

O 

O 


0 

E 

0 

z 

0 

§!;o 
—  CL 

25 

0-  QJ 

LU  CL 
CL  ^ 

-i  .2 

Z  0 

z  ^ 

LU 
H 
Z 
< 


0 

0 

E 

0 

z 

0 

+-» 

3 


C 

< 

0 

0 


0 

CO 

tr 

S' 

0 

3 


0 

O) 

c 

0  _ 

|!< 
CL  LL 


<< 


d 

>> 

O 

c 

0 

3 

cr 

0 


0 

O) 

c 

0  ^ 
OC  P 

lU  rr^ 


>-  a 

b  9? 


O' 

0 

IL 


LU 


0 

0 


O) 

5 

C 

< 

I  W 

0 


c 

0 

Z 

«  0 
^  z 

^  0 
^  z 

c 

<15  r- 

4^  L. 

0  c- 

4~*  t 

E 

3 

|i 

|i 

O 

t2  O 

R 

O 

<  o 

<  o 

c 

g 

’0 

c 

0 

E 

a 

S 

*o 

0. 

■o  ^ 

IL  S 


y  T3 
CL  <n 

ii 

13 

5§ 

0 
0 
E 
0 
z 

S 

3 

ts  o 

<  O 


c 

o 

0 

c 

0 

E 


•i?s: 

CL 

|§ 

-2  u. 

LU  4^ 
CL  C 
>-  O 

ii 

15 


0 

to 

cc 

o 

.i5 

t 

uj; 

LU 

CL 


LU 


c 

0 

g 

t: 

LU. 


0 

to 

cn 

I 

o 

CL 

•o 

0 

■§ 

0 

cr 

0 

> 

1 

s 


I? 

Ss 

CL  LL 

h  0- 

*7  OC 
<LU, 


0 

TJ 

O 

o 

0 

0 

■o  tr 

o  z 

0 


0 

O) 

0 

S' 

C 

0 

3 

CT 

2 

0 


y: 

< 

LL 


LU 

CL 


Z 

LU 


3 

C 

3 

O 


0 
C 

c 
0 
cO 

is  II  I 

O 

<  _ 

5  Oq- 

9- -Si 


<< 


\^(D 

<1 


0 

0 

E 

0 

z 

V  g, 

i| 

p 

|l 

^  z 

p 

|i 

^  z 

c 

S  c 

c= 

S  c 

E 

3  E 

3  i 

3  E 

0 

0 

E 

0 


o 

<  o 


ti  o 
<  O 


=3  = 
C  O 
<  O 


B  c 

II 

ts  o 

<  O 


&vZ 

|| 

_ _ I  "O  CO 

"’coiul' 

P  2  EQ  Z  — I 

i  05 

Z  0  Z  2  rrt 

LU  £  LU  <  ^ 

H  H  H  7:  ^ 
5  C  5  m  W 

<  2  ^  c  ^ 

0  •=  0  CO  § 

E;i  EZ^ 
0  0  0 
Z  Q  Z  -Ss  c 

3  C 

S  § 


Q 

O 


I 

K 

*c 
LU  to 

io 

g 

<  to 

(P  LL 

O  I 

^  o 

0 

DC  S 

t?) 

^  0 

0  cr 


c 

0 

■D 

LU  S 

C  0 

Q  <  I 

— 'z  ^ 
■gm  B, 

|<  = 

0  0  E 

iiC  2 
2^  c  *£ 
0  .2>^ 
c  0  DC 

W  fc-  .  . 

•c  O  iiC 
CL  LL  LL 


Attribute  Names;  ANTENNA-TYPE-BAND  Selection  Identifier  (PK) 
Column  Names:  Band_SelectionJD  CHAR(35)  NOT  NULL 


9-  *■£  ^ 
>-  o  ^ 

tail 

i”5is 


2  m'Q< 


05  WZ 


Ch  B)< 

tl  7"  CD  .. 

<0-^1 

2  c  2  « 
E  ic  E  z 

CO  0)  CO 

z  a  z  £ 

4!=  ^ 

c  c  CO  C 

UJ  UJ  I-  < 


2  z  B  -g  lii  CT  z 


«i<  = 

«.S 

(0  Sr  qT  E 
z  ^  ^  £ 

3  c  CD  DC 
O  -C  o 
O  0-  Li.  LL 


Z  Q 
liJ  ““I 

o 

^  CO  bd 
<2to' 

I  ss 

5  rt  ^ 

S  c  ^ 
3  E  « 
€  =  E 

4^  O  -C 
<00. 


« 

Hf  H; 
m  m 

9:  «3i 

3  2  3 
O  jfO 
111  o 

0)  •■£  <i5 
Ei  E; 

cd  (U  cd 
Z  Q  Z 

*.p  '.P  ^ 

c  c  CO 
HI  LU  h- 


m  Q 


ts  O  w 

<OQ- 


Entity  Name:  TRANSMISSION-RECEPTION-EQUIPMENT-TYPE 

Entity  Definition:  The  classification  of  the  equipment  that  is  a  transmitter,  receiver  or  transceiver. 


Q 

O 


3 

Z 

9? 

T 

m  Eq 

2. Ill 

^  O’.® 

S,ife| 

U.  «  2/5 

DC  g  S 

®  i  I 

ZS  c 

®Ei 

^  ‘C  ^ 
CO  ti  o 
H<0 


CO 

(D 

OC 

I 

3 

O 


0 

Z  8 

LU  CO 
20 
Q.  I 

50 

O 

lU 

CO  S 

o  to 

C  0) 

ffoc 

*2  ' 
0  — 
CE 


0 

■D 

CO 

O 

0 

0 

o 


0 


2 
!  oc  — 


9l' 

-l-BCS 

0  D- 
•=  LU  ^ 

_ 

-  w  .2 

ara® 

c  0  CE 
•c  o  ^ 

Q.  Li.  U. 


Appendix  B.  IDEFO  Antenna  Model 

The  following  diagrams  show  the  activity  model  of  the  OE-254()/GRC  antenna  and  schema 
for  each  activity,  input,  control  and  output. 
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Appendix  C.  C4I  Modeling  and  Simulation 

In  this  appendix,  the  hierarchy  of  communications  systems  is  described  and  a  brief  discussion 
of  types  of  simulations  is  provided.  A  detailed  discussion  is  also  provided  concerning  the  model¬ 
ing  of  radiowave  propagation  to  arrive  at  accurate  received  power  and  link  margin  calculations. 
The  importance  of  developing  simulations  based  on  accurate  models  is  discussed  in  the  need  for 
automation  and  determining  the  perishability  of  information. 

C.l  Network  Layering 

Communications  networks  are  modeled  according  to  the  network  architecture.  The  most 
common  network  architecture  for  computer  networks  is  the  International  Standards  Organization 
(ISO)  Open  Systems  Interconnect  (OSI)  model  (Figure  C.l).  There  are  other  network  architec¬ 
tures  based  on  the  OSI  model,  such  as  the  Internet  Protocol  (IP)  architecture,  Systems  Network 
Architecture,  and  Digital  Network  architecture,  but  the  OSI  model  provides  the  framework(34). 
The  network  control  functions  are  performed  in  the  session,  transport,  network,  and  data  link  layer. 
The  radios,  antenna  and  associated  hardware  are  the  physical  layer. 


Application 
Presentation 
Session 
Transportation 
Network 
Data  Link 
Physical 

Figure  C.l  Open  Systems  Interconnection  Reference  Model  Architecture(34) 
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C.2  Abstract  vs.  Detail  Modeling 


The  tension  between  detailed  and  abstract  modeling  (often  referred  to  as  the  fidelity  of  the 
model)  is  a  fundamental  issue  for  the  network  simulator.  Detailed  models  provide  accurate  results, 
but  can  take  a  long  time  to  develop  and  consume  large  amounts  of  computer  resources  to  generate 
results.  Abstract  models  typically  generate  results  much  more  quickly,  but  their  results  may  not 
be  useful  if  too  many  simplifying  assumptions  have  been  made  in  the  abstraction(16,  22).  The 
key  input  from  the  network  engineer  is  recognition  of  the  key  components  of  the  system  that  must 
be  modeled  in  detail  and  what  abstractions  can  be  used  to  reduce  simulation  run  times(4).  An 
important  consideration  when  modeling  communications  systems  is  communication  realism  in  the 
network  due  to  changes  on  the  battlefield.  The  temporal  effects  of  the  environment  on  a  radio  path 
is  often  left  out  of  many  battlefield  simulations  encompassing  communications.  Environmental 
effects  are  modeled  in  the  links,  and  are  measured  in  data  errors  and  received  signal  levels. 

C.3  Real-Time  vs.  Analytical 

There  are  two  types  of  simulations  in  use  today,  real-time  and  analytical.  Real-Time  simula¬ 
tions  provide  output  in  near  real-time  (approximately  every  5  seconds)  for  use  by  other  simulations 
(distributed  interactive  simulations)  or  humans  (training  and  war-gaming).  Real-time  simulations 
often  required  more  abstraction  to  meet  the  5  second  requirement,  however,  communications  re¬ 
alism  in  Real-Time  simulations  is  necessary  in  a  dynamic  environment  to  provide  feedback  when 
communications  are  operating  reliably,  stressed  or  no  longer  possible.  If  a  communications  link 
experiences  a  loss  for  a  fraction  of  a  second,  the  digital  message  which  had  been  transmitted  over 
several  seconds  or  minutes  may  have  to  be  resent.  However,  in  a  voice  message,  the  same  error 
may  cause  an  insignificant  or  even  unnoticeable  chirp.  Analytical  simulations  can  “elongate”  time 
and  be  more  detailed,  but  are  less  useful  in  interactive  or  distributed  simulations.  Communications 
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realism  is  also  important  in  these  simulations  to  determine  reliability  and  the  causes  of  failures  in 
the  network. 

Expanding  the  previous  discussion,  the  use  of  “visual  physics”,  the  practice  of  making  some¬ 
thing  look  realistic,  whether  or  not  physically  correct,  is  common  in  real-time  simulations.  By 
contrast,  analytic  simulations  rely  heavily  on  deterministic,  discrete,  closed,  event-driven  models 
which  are  reproducible  and  accurate.  Many  of  the  analytic  models  have  undergone  a  rigorous 
validation  and  verification  process  to  ensure  the  accuracy  and  truthfulness  of  their  algorithm.  In 
order  to  verify  that  the  real-time  simulation  is  accurately  reflecting  real  world  expectations,  an¬ 
alytical  simulations  based  on  measured  data  must  be  completed(31).  The  verification,  validation 
and  accreditation  process  of  a  realistic  communications  algorithm  is  the  basis  for  this  thesis. 

C.4  Constructive,  Virtual  and  Live  Simulations 

Simulations  are  also  described  as  constructive,  virtual  and  live.  Constructive  simulations  re¬ 
quire  little  or  no  interaction  from  humans.  These  are  usually  purely  analytical.  Virtual  simulations 
require  some  interaction  between  the  computer  and  human.  Manned  simulators  and  war-gaming 
exercises  are  examples  of  virtual  simulations.  Live  simulations  axe  real-time  experiments,  training 
exercises,  demonstrations  and  tests  that  take  place  in  a  field  like  environment(5). 

C.5  Modeling  Radiowave  Propagation 

Figure  C.2  is  a  block  diagram  of  a  satellite  communications  link,  emphasizing  the  sources 
of  signal  loss  and  noise.  In  the  figure,  a  signal  loss  is  distinguished  from  a  noise  source  by  a  dot 
pattern  or  line  pattern,  respectively.  The  contributors  of  both  signal  loss  and  noise  are  identified 
by  a  crosshatched  line  pattern.  There  are  21  sources  of  degradation  cataloged  by  the  figure.  This 
is  only  a  partial  list(32).  This  section  will  discuss  the  sources  of  signal  loss  and  noise  as  a  result  of 
the  environment. 
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Figure  C.2  Satellite  Transmitter-to-Receiver  Link  with  Typical  Loss  and  Noise  Sources(32) 


There  are  many  environmental  factors  which  degrade  communications  over  the  path.  Many 
of  these  factors  are  temporal  and  cause  severe  fading  or  increased  noise  when  they  occur.  Figure 
C.3  shows  some  of  the  environmental  factors  which  can  affect  communications (14). 


C.  6  Ionospheric  effects 

Radio  frequency  waves  propagating  in  the  ionosphere  experience  dissipative  attenuation  which 
becomes  increasingly  important  with  decreasing  frequency.  A  principal  mechanism  of  attenuation  is 
collisions  of  free  electrons  with  neutral  atoms  and  molecules.  An  electromagnetic  wave  propagating 
in  a  plasma  imparts  an  ordered  component  of  velocity  to  the  electrons  but  the  electrons  lose  some 
of  the  associated  energy  in  the  collision  process.  Hence  the  electromagnetic  wave  is  attenuated.  For 
frequencies  above  about  30  MHz  or  for  transverse  propagation  of  the  ordinary  wave,  the  attenuation 
constant  varies  inversely  with  frequency  squared  and  can  be  found  using  Equation  C.l  (13): 
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Figure  C.3  Schematic  Presentation  of  Propagation  Impairment  Mechanisms(14) 


a  =  8.686 


/  Nq^v  \ 

\2meonrCLj‘^  J 


dB/m 


where: 

N  is  the  electron  density  of  the  ionosphere  in  electrons/m® 

Tir  is  the  real  part  of  the  index  of  refraction 
q  =  1.6022a:10-i®  C 
m  =9.1096x10-3^ 

Co  =  8.854x10-^2  F/m 

c  =  2.9979x10®  m/s 

a;  =  27r/  with  f  in  Hz 
and  V  is  the  collision  frequency  in  Hz. 


(C.l) 
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C.  7  Clouds  and  Fog 


Clouds  and  fog  are  both  composed  of  minute  water  droplets  or  ice  crystals  suspended  in  air. 
Fog  forms  near  the  Earth’s  surface,  and  clouds  occur  at  higher  levels.  The  water  droplets  in  fog 
and  clouds  cause  attenuation  of  electromagnetic  waves  and  add  noise  by  acting  as  an  elementary 
antenna  that  radiates  energy.  The  attenuation  caused  by  clouds  for  frequencies  between  IGHz  and 
50GHz  can  be  found  by  using  Equation  C.2,(13) 


ap  =  ^0. 


. «  . «  bTT  ^ 

4343— 7m 

A 


K,-l 


Kc  +  2 


]) 


pi  dB/km 


(C.2) 


where 

ap  is  the  attenuation  coefficient  (dB/km) 

Acm  is  the  wavelength  (cm) 

Kc  is  the  complex  relative  dielectric  constant  of  water 

Pi  is  the  liquid  water  content  of  the  cloud  (g/m^) 

and  the  noise  caused  by  the  cloud  can  be  found  using  Equation  C.3, 

Tb  =  T,e-^  +  Ti{\-e-'^)  (C.3) 

where  is  the  brightness  temperature  when  a  source  at  a  temperature  of  Ts  is  viewed  through 
an  absorbing  region  having  an  effective  temperature  of  Ti.  The  parameter  r  represents  the  integral 
of  the  power  attenuation  constant  across  the  path.  This  noise,  is  then  added  to  the  system 
temperature,  Tgysi  through  the  antenna(13).  The  attenuation  and  noise  temperature  as  a  result  of 
clouds  as  a  function  of  frequency  is  shown  in  Table  C.l. 


C-6 


Case 

Lower  Cloud 

Upper  Cloud 

Remarks 

S-Band 
(2.3  GHz) 
Zenith 

X-B 

(8.5’ 

Zei 

and 

GHz) 

1th 

X-6and 
(10  GHz) 
Zenith 

Density 

g/ar 

Base 

kn 

Top 

kM 

Thick¬ 

ness 

kn 

.Density 

gV 

Base 

km 

Top 

kM 

Thick¬ 

ness 

kn 

T{lt)- 

T(K) 

UdB) 

T{IC) 

A(dB) 

1 

- 

> 

- 

- 

- 

Clear  Air 

2.15  .035 

2.78  ( 

.45 

3.05 

.049 

2 

0.2 

1.0 

1.2 

0.2 

- 

- 

- 

- 

Thin 

Clouds 

2.16  .036 

2.90 

.047 

3.22 

.052 

3 

- 

- 

- 

- 

0.2 

3.0 

3.2 

0.2 

2.16  .036 

2.94 

.048 

3.28 

.053 

4 

0.5 

1.0 

1.5 

0.5 

- 

- 

- 

- 

2.20  .036 

3.55 

.057 

4.12 

.066 

5 

- 

- 

- 

- 

0.5 

3.0 

3.5 

0.5 

2.22  .037 

3.83 

.062 

4.50 

.073 

6 

0.5 

1.0 

2.0 

1.0 

- 

- 

- 

- 

Medium 

Clouds 

2.27  .037 

4.38 

.070 

5.27 

.084 

7 

- 

- 

- 

- 

0.5 

3.0 

4.0 

1.0 

2.31  .038 

4.96 

.081 

6.06 

.098 

8 

0.5 

1.0 

2.0 

1.0 

0.5 

3.0 

4.0 

i 

1.0 

Heavy 

Clouds 

2.43  .040 

6.55 

.105 

8.25 

.133 

9 

0.7 

1.0 

2.0 

1.0 

0.7 

3.0 

4.0 

1.0 

2.54  .042 

8.04 

.130 

10.31 

.166 

10 

1.0 

1.0 

2.0 

1.0 

1.0 

3.0 

4^0 

1.0 

2.70  .044 

10.27 

.166 

13.35 

.216 

11 

l.O 

1.0 

2.5 

1.5 

1.0 

3.5 

5.0 

1.5 

Very 

Heavy 

Clouds 

3.06  .050 

14.89 

.245 

19.66 

.326 

12 

1.0 

1.0 

3.0 

2.0 

1.0 

4.0 

6;o 

2.0 

3.47  .057 

20.20 

.340 

26.84 

.457 

Table  C.l  Sample  Cloud  Models  and  S-,  X-,  K-Band  Zenith  EfFects(14) 


C.8  Rain 

Raindrops,  like  clouds  but  more  severe,  cause  attenuation  of  radio  waves  by  both  absorption 
and  scatter.  Absorption  involves  dissipation  of  some  of  the  energy  of  an  electromagnetic  wave  as 
heat.  Scatter  involves  diversion  of  some  of  the  energy  of  the  wave  into  directions  other  than  the 
forward  direction.  The  attenuation  coefficient  from  rain  can  be  found  using  Equation  C.4  (13) 


7  =  kR^  dB/km  (C-4) 

where  R  is  the  rain  rate  in  mm/hr,  and  k  and  a  have  been  recorded  in  Table  C.2  for  the 
index  of  refraction  of  water  at  20^  C  and  spheroidal  drops  in  the  range  of  1-150  mm/h. 

The  rain  rate  for  different  geographic  areas  around  the  world  have  been  measured  and  regions 
have  been  identified  by  their  rain  rate  climate.  These  eight  regions  are  shown  in  Figures  C,4  and 
C.5  as  well  as  the  rain  rates  exceeded  as  a  percentage  of  the  year.  Table  C.3  provides  a  more 
detailed  chart  for  the  rain  rates  exceeded  in  regions  A  to  H  as  a  percentage  of  the  year. 
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Frequency 

(GHz) 

ky 

ttH 

ttv 

1 

00000387 

0-0000352 

0-912 

0-880 

2 

0-000154 

0-000138 

0-963 

0-923 

4 

0-000650 

0-000591 

1-121 

1-075 

6 

0-00175 

0-00155 

1-308 

1-265 

7 

0-00301 

0-00265 

1-332 

1-312 

8 

0  00454 

0-00395 

1-327 

1-310 

10 

0-0101 

0-00887 

1-276 

1-264 

12 

0-0188 

0-0168 

1-217 

1-200 

15 

0-0367 

0-0335 

1-154 

1-128 

20 

0-0751 

0-0691 

1-099 

1-065 

25 

0-124 

0-113 

1-061 

1-030 

30 

0-187 

0-167 

1-021 

1-000 

35 

0-263 

0-233 

0-979 

0-963 

40 

0-350 

0-310 

0-939 

0-929 

45 

0-442 

0-393 

0-903 

0-897 

50 

0-536 

0-479 

0-873 

0-868 

•  60 

0-707 

0-642 

0-826 

0-824 

70 

0-851 

0-784 

0-793 

0-793 

80 

0-975 

0-906 

0-769 

0-769 

90 

1-06 

0-999 

0-753 

0-754 

100 

1-12 

1-06 

0-743 

0-744 

120 

1-18 

1-13 

0-731 

0-732 

150 

1-31 

1-27 

0-710 

0-711 

200 

1-45 

1-42 

0-689 

0-690 

300 

1-36 

1-35 

0-688 

0-689 

400 

1-32 

1-31 

0-683 

‘0-684 

Laws  and  Parsons  dropsizc  distribution  [7] 

Gunn  and  Ginzer  terminal  velocities  (8) 

Index  of  refraction  of  water  at  20*  C  after  Ray  [9] 

Values  of  *M.  *v.  «h*  *v  fo'’  apheroidal  drops  [10, 1 1]  in  the  range  1-150 mm/h 

Table  C.2  Regression  Coefficients  for  Estimating  the  Attenuation  Coefficients(14) 


Percent 

RAIN  CLirMTE  REGION 

Minutes 

per 

Year 

of  Year 

A 

*1 

B 

CNt 

CD 

C 

m 

E 

F 

G 

H 

0.001 

28.5 

45 

57.5 

70 

78 

90 

108 

126 

165 

66 

185 

253 

5.26 

0.09 

0.002 

21 

34 

44 

54 

62 

72 

89 

106 

144 

51 

157 

220.5 

10.5 

0.18 

0.005 

13.5 

22 

28.5 

35 

41 

50 

64.5 

80.5 

118 

34 

120.5 

178 

26.3 

0.44 

0.01 

10.0 

15.5 

19.5 

23.5 

28 

35.5 

49 

63 

98 

23 

94 

147 

52.6 

0.88 

0.02 

7.0 

11.0 

13.5 

16 

18 

24 

35 

48 

78 

15 

72 

119 

105 

1.75 

0.05 

6.4 

8.0 

9.5 

11 

14.5 

22 

32 

52 

8.3 

47 

86.5 

263 

4.38 

0.1 

4.2 

5.2 

6.1 

7.2 

9.8 

14.5 

22 

35 

5.2 

32 

64 

526 

8.77 

1.5 

2.8 

3.4 

4.0 

4.8 

6.4 

9.5 

14.5 

21 

3.1  j 

21.8 

43.5 

1052 

17.5 

0.7 

1.5 

1.9 

2.3 

2.7 

3.6 

5.2 

7.8 

10.6 

1.4 

12.2 

22.5 

2630 

43.8 

1.0 

0.4 

1.0 

1.3 

1.5 

1.8 

2.2 

3.0 

4.7 

6.0 

0.7 

8.0 

12.0 

5260 

87.7 

2.0 

0.1 

0.5 

0.7 

0.8 

1.1 

1.2 

1.5 

1.9 

2.9 

0.2 

5.2 

10520 

175 

5.0 

0.2 

0.3 

0.3 

0.0 

0.5 

0.0 

1.8 

1.2 

26298 

438 

Table  C.3  Rain  Rates  Exceeded  as  a  Function  of  Percentage  of  Year,  for  Regions  A  to  H(13) 


C-8 


Man  TfififtraMt  MTra^cal:  Trapieil! 

Sa  TtmiralOnfl  So  ftMllHit  Ql  WM  Do  Modarata 

ODt  TiiiitMMMri  00  Cmllmimt  Br  AiU  Bh  wm 


iaw|HM<a  tPail 


Figure  C.4  Global  Rain  Rate  Regions (13) 


WORLD 


PERCENTAGE  OF  YEAR 

Figure  C.5  Rain  Rates  as  a  Function  of  Percent  of  Year  Exceeded(13) 


HI 


I 


The  attenuation  over  the  path  is  a  function  of  the  path  length  traveling  through  the  rain.  For 
satellite  paths,  it  is  necessary  to  measure  the  path  length  as  a  function  of  the  height  of  the  rain 
storm.  For  latitudes  below  36°,  use  a  rain  height  of  4  km.  For  latitudes  of  36°  and  above,  use  the 
Equation(13) 


J?  =  4.0  -  0.75(0  -  36°) 


(C.5) 


where  0  is  the  latitude  in  degrees. 

Then  by  using  trigonometry,  the  path  length  can  be  found  as  a  function  of  the  height  and 
elevation  angle,  9  (13) 


L  = 


I  sin  0  ’ 


2H 


(sin2  04.^)i/2+sin^’ 


10° 
9  <  10° 


(C.6) 


where  9  is  the  elevation  angle  and  Ktq  is  the  effective  earth  radius. 

Therefore  we  can  solve  for  the  attenuation  across  the  length  of  the  path  affected  by  the  rain 
using  (13) 


A  =  'iLvp  (C.7) 

where  Vp  is  a  factor  to  account  for  the  variability  of  the  rain  rate  along  the  path  (known  as 
an  empirical  path  reduction  factor).  We  can  first  solve  the  attenuation  problem  for  a  probability 
of  0.01,  for  which  Vp  is  given  by 


1 

“  l  +  O.O45(Lcos0) 


(C.8) 
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Then  we  can  determine  the  attenuation,  Ap,  equaled  or  exceeded  with  a  probability  other 


than  0.01  using  (13) 


Ap  =  Ao.oi0.12p-(‘>®'‘®+o«^3‘°s*’)  (C.9) 


The  degradation  of  the  signal  to  noise  ratio  can  be  found  using  the  same  Equation  as  was 
used  for  clouds  in  the  previous  section.  The  effect  of  atmospheric  absorption  from  rain  can  be  large, 
as  Figure  C.6  demonstrates  (SNR  is  shown  as  C/X  in  this  figure). 


Figure  C.6  Degradation  in  Signal-to-Noise  Ratio  (C/X)  versus  Atmospheric  Absorption,  for  Var¬ 
ious  Values  of  T(14) 


C.9  Sand  and  Dust  Storms  (Haboobs) 

Haboobs  are  storms  of  particulates  which  act  on  radio  waves  with  the  same  mechanisms  as 
rain  and  clouds.  A  haboob  is  a  unique  storm  primarily  affecting  equatorial  regions  in  the  rain  rate 
climate  regions  F,  G,  and  H  (refer  back  to  Figure  C.4).  Strong  gusts  from  the  cold  down  draft 
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within  the  thunderstorm  produce  the  dust  storm.  The  air  is  usually  fairly  humid,  leading  to  a 
significant  uptake  of  water  by  the  dust  which  will  increase  the  propagation  eifects  (Figure  C.7). 


Figure  C.7  Cross-Section  through  a  Thunderstorm  that  is  Producing  a  Haboob(14) 

To  find  the  attenuation  as  a  result  of  a  haboob,  a  model  of  the  dust  cylinder  must  be  created 
to  calculate  the  amount  of  dust  in  the  path  (Figure  C.8).  The  dust  is  assumed  to  be  of  uniform 
density  horizontally  with  all  of  the  significant  dust  contained  within  a  symmetrical  right  cylinder 
of  diameter  10  km.  The  dust  density  falls  off  with  height,  following  a  power  law  decay,  the  index 
of  which  is  determined  by  the  initial  visibility  at  a  height  of  2m. 

The  attenuation  can  be  found  using  the  same  Equations  as  rain  for  the  path  length  and 
replacing  7  by  (13) 


189  a  r  SKi 
V  A  [{Kr  +  2)^  +  Kf 


(C.IO) 


where  V  is  the  visibility  in  km,  a  is  the  average  particle  radius  in  m.  Am  is  the  wavelength  in 
m,  and  tr  —  —  jKi  is  the  relative  dielectric  constant  of  the  dust. 
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Figure  C.8  Schematic  of  the  Dust  Cell  Model(14) 


Assuming  a  visibility  of  10m  and  all  dust  particles  are  spherical  and  uniformly  distributed 
along  the  path,  the  attenuation  in  dB/km  is  shown  in  Figure  C.9.  The  lower  line  (with  dots)  is 
for  a  0.3%  mixture  of  water  and  dust  (g  H20/g  soil).  The  upper  line  (with  x’s)  is  for  a  higher 
concentration  of  water  (10%  (g  H20/g  soil)). 

C.IO  Determining  Received  Power  and  Link  Margin 

The  power  received  at  the  communication  receiver  is  a  function  of  the  transmitted  power,  gain 
of  the  transmit  antenna,  path  loss  and  antennuation,  and  losses  from  the  antenna,  cable,  connector 
and  receiver.  The  received  power  is  expressed  as  C.ll  (32,  38): 

P,  =  (C.ll) 

LgLo 


where: 

Pr  is  the  received  signal  power  in  Watts; 
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Figure  C.9  Attenuation  as  a  Function  of  Frequency  for  Falling  Dust  Particles(14) 

EIRP  is  the  Effective  Isotropic  Radiated  Power  in  Watts  and  can  be  expressed  as  C.12: 

EIRP  =  PtGt  (C.12) 

where  Pt  is  the  transmitted  power  in  Watts  and  Gt  is  the  gain  of  the  transmit  antenna; 

Gr  is  the  gain  of  the  receive  antenna; 

La  is  the  path  loss  expressed  as  C.13: 


La 


y  Ka 
(c/f))  R‘a’ 


where: 

c  is  the  speed  of  light  (cr;  3  x  10®  m/s), 

/  is  the  frequency  in  Hz, 

Ks  is  the  constant  of  attenuation  over  the  radiowave  path, 


(C.13) 
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Rs  is  the  communication  path  distance  in  meters,  and 


Is  is  the  antennuation  exponent  on  the  communication  path  (Is  =  2  for  free  space  communi¬ 
cations  such  as  air  to  air  and  air  to  ground,  and  /«  =  4  for  ground  to  ground  communications  (38)); 
and  Lo  are  losses  from  the  antenna,  cable,  connector  and  receiver. 

The  link  margin  (or  safety  margin)  is  an  expression  which  relates  the  received  power  and  the 
receiver  thermal  noise  power  spectral  density  with  a  required  bit  energy  per  noise  power  spectral 
density  to  yield  a  specified  error  probability.  The  received  signal  power  (no  noise)  is  the  product 
of  the  received  energy  per  bit  and  the  information  rate  C.14: 


Pr  =  (C.14) 

where  Ej,  is  the  received  energy  per  bit  and  Rh  is  the  received  information  rate  or  roughly 
the  baseband  bandwidth. 

Therefore,  the  link  margin,  (M),  can  be  expressed  as  C.15: 


M  = 


(C.15) 


where  No  is  the  noise  power  spectral  density  to  the  Predetection  output  of  the  receiver  and 
is  expressed  as  C.16  (32): 


No  =  GkT^sW 


(C.16) 


where: 

G  is  the  gain  of  the  receiver, 

K  is  Boltzmann’s  constant  (1.38  x  10“^^  W-K/Hz), 
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T°  is  the  system  effective  temperature,  and 


W  is  the  bandwidth  of  the  received  signal  in  Hertz. 


The  system  effective  temperature  is  expresses  as: 


T°  =TX  +  -  1)290K 


(C.17) 


where  is  the  antenna  temperature  and  Fi  and  Fr  are  the  noise  figure  of  the  antenna  cable 
and  coupler  and  the  noise  figure  of  the  receiver,  respectively.  Figure  C.IO  represents  a  simplified 


schematic  of  a  receiving  system  (32). 


Antenna 


Figure  C.IO  Major  Noise  Contributors  of  a  Receiving  System(32) 


C.IJ  Need  for  Automation 

Current  methods  of  manual  network  design  and  analysis  use  acetate  overlays  on  paper  maps, 
self-adhesive  dots  for  unit  location,  push  pins  for  nodes,  and  tape,  grease  pencil  or  colored  string 
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for  transmission  routes.  Link  performance  is  driven  solely  on  basic  specifications  for  line  of  site 
distance,  terrain  obstacles,  and  average  power  available  at  the  transmitter.  Network  topology  is 
often  changed  several  times  during  the  planning  stage,  and  then  reactive  during  mission  operation. 
For  example,  a  site  which  has  been  selected  to  maximize  subscriber  access  may  be  shifted  to  satisfy 
terrain  constraints,  and  then  this  site  may  be  adjusted  again  because  of  logistics  considerations. 
By  this  time,  the  subscriber  access  has  been  degraded  and  must  be  revisited.  This  problem  will 
be  many  times  more  difficult  with  the  implementation  of  the  Army’s  Integrated  System  Control 
(ISYSCON)  which  will  require  the  coordination  of  all  communications  assets  including  Enhanced 
Position  Locating  and  Ranging  System  (EPLRS),  Joint  Tactical  Information  Distribution  System 
(JTIDS),  Satellite  Communications  System  (SATCOM),  Combat  Net  Radio  (CNR)  and  other 
communications  assets  at  all  levels  of  command.  Additionally,  as  the  operation  develops,  the 
network  becomes  mobile  on  the  ground(6). 

Computer  assistance  in  the  network  design  process  will  increase  the  planner’s  effectiveness  and 
reduce  the  major  part  of  the  work  load.  It  will  allow  planners  to  develop  plans  in  the  reduced  time 
necessary  to  support  the  mobility,  fiexibility,  and  robustness  required  of  today’s  communications 
equipment  in  the  rapidly  changing  tactical  environment(6).  Additionally,  the  plan  that  is  developed 
will  be  available  for  direct  transfer  to  others  and  the  communications  network  can  be  simulated  in 
advance  (simulated  war  game)  based  on  operational  plans  as  they  develop.  Applying  realism  in  the 
simulation  avoids  mistakes  commonly  made  during  network  planning  when  using  basic  specifications 
in  the  manual  method  and  gives  decision  makers  more  realistic  expectations  of  the  communications 
backbone. 

Despite  the  extensive  research  during  the  past  decade  on  network  performance  assessment 
and  optimization,  the  need  to  develop  automated  tools  to  assess  system  performance  in  more  than 
one  network  layer,  responsive  to  the  dynamic  battlefield  environment  still  exists. 
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C.12  Perishability  of  Information  and  Situational  Age 

Certain  types  of  information  is  perishable  and  loses  usefulness  if  not  updated  frequently.  An 
example  of  this  is  situational  age.  Consider  a  sensor  that  takes  a  snapshot  in  time  of  an  enemy  tank. 
The  tank  is  moving,  so  the  sensor  reports  the  tank’s  direction  and  speed.  However,  immediately 
after  this  information  is  sent,  the  degree  of  uncertainty  of  the  tanks  position  increases  with  time 
(Figure  C.ll).  The  tank  may  have  changed  direction  or  speed. 

Situational  Age:  Position  vs.  Time 


Unless  the  sensor  updates  this  information,  it  becomes  useless  as  the  degree  of  uncertainty 
grows.  In  order  for  the  information  to  be  useful,  it  must  be  received  and  acted  upon  before  the 
tank  could  leave  the  kill  radius  of  the  weapon  system  chosen  to  destroy  if,  or  the  sensor  must 
update  the  decision  maker  and/or  weapon  system  to  ensure  the  tank  is  within  the  kill  radius  of 
the  weapon  when  it  arrives.  Information  perishability  is  an  important  metric  of  C4I  systems  and 
relies  on  an  accurate  model  of  the  radiowave  propagation  path.  A  haboob  which  hides  the  target 
from  the  sensor  is  important  to  include  in  the  model  and  may  result  in  a  different  result  during 
a  wargame  simulation.  This  case  is  also  true  if  the  target  is  initiated  by  an  observer  or  sensor; 
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however,  information  needed  to  update  the  weapon  system  and  achieve  a  “kill”  upon  arrival  is  lost 
as  a  result  of  environmental  conditions  between  the  observer/sensor  and  weapon  system. 

C.13  Modeling  Temporal  Events 

Environmental  conditions  discussed  in  this  appendix  are  time  dependent.  IDEF2  provides  a 
model  by  which  these  events  can  be  captured  and  described(15).  This  model  can  be  included  in  the 
architectural  design  process  recommended  by  this  thesis,  to  capture  and  include  in  C4I  simulations, 
the  radiowave  propagation  effects  discussed  in  this  appendix. 
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Appendix  D.  IDEF4  Overview 


The  following  overview  of  the  IDEF4  Object-Oriented  Design  Method  by  Knowledge  Base 
Systems,  Inc.  is  provided,  with  permission,  to  encourage  further  standardization  of  the  simulation 
object  development  process.  Simulation  developers,  as  computer  programmers,  need  the  docu¬ 
mentation  produced  by  IDEF4  to  identify  existing  classes,  instances,  and  object  parameters  and 
behavior.  The  IDEFd  products  would  also  be  used  to  validate  and  approve  objects  for  storage  in 
an  ODBMS  in  the  distributed  simulation  network. 
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IDEF4  Object-Oriented  Design  Method 


The  intuitive  nature  of  object-oriented  programming  makes  it  easier  to  produce  code.  Unfortunately,  the 
ease  with  which  software  is  produced  also  makes  it  easier  to  create  software  of  poor  design,  resulting  in 
systems  lacking  re-usability,  modularity,  and  maintainability.  The  IDEF4  method  is  designed  to  assist  in 
the  correct  application  of  this  technology. 

With  over  thirty  object-oriented  design  methods  in  existence  today,  why  should  we  chose  IDEF4?  Most 
importantly,  IDEF4  views  object-oriented  design  as  part  of  a  larger  system  development  framework, 
rather  than  an  object-oriented  analysis  and  design  method  that  is  ambiguous.  IDEF4  stresses  the 
object-oriented  design  process  over  the  graphical  syntax,  using  the  graphical  syntax  and  diagrams  as 
aids  to  focus  and  communicate  important  design  issues.  IDH^4  is  significantly  different  from  other 
object  design  methods,  primarily  in  its  support  of  "least  commitment"  strategies  and  its  support  for 
assessing  the  design  impact  of  the  interaction  between  class  inheritance,  object  composition,  functional 
decomposition,  and  polymorphism. 

IDEF4  Concepts 

IDH’4  divides  the  object-oriented  design  activity  into  discrete,  manageable  chunks.  Each  subactivity  is 
supported  by  a  graphical  syntax  that  highlights  the  design  decisions  that  must  be  made  and  their  impact 
on  other  perspectives  of  the  design.  No  single  diagram  shows  all  the  information  contained  in  the  IDEF4 
design  model,  thus  limiting  confusion  and  allowing  rapid  inspection  of  the  desired  information. 

Carefully  designed  overlap  among  diagram  types  serves  to  ensure  compatibility  between  the  different 
submodels.  The  IDEF4  method  allows  the  designer  to  easily  make  trade-offs  between  class  composition, 
class  inheritance,  functional  decomposition,  and  polymorphism  in  a  design.  E)EF4  is  more  than  a 
graphical  syntax-the  graphical  syntax  provides  a  convenient  framework  for  navigating  an  evolving 
object-oriented  design  that  is  ultimately  specified  on  class  invariant  data  sheets  and  method  set 
contracts. 

Figure  1  shows  the  basic  organization  of  an  IDEF4  model.  Conceptually,  an  IDH^4  model  consists  of 
two  submodels,  the  class  submodel  and  the  method  submodel.  The  two  submodels  are  linked  through  a 
dispatch  mapping.  These  two  structures  capture  all  the  information  represented  in  a  design  model.  Due 
to  the  size  of  the  class  and  method  submodels,  the  IDEF4  object  designer  never  sees  these  structures  in 
their  entirety.  Instead,  the  designer  makes  use  of  the  collection  of  smaller  diagrams  and  data  sheets  that 
effectively  capture  the  information  represented  in  the  class  and  method  submodels. 


Figure  1.  Organization  of  the  IDEF4  Model 


The  class  submodel  is  composed  of  the  following  diagram  types:  1)  Inheritance  diagrams  that  specify 
class  inheritance  relations;  2)  Type  diagrams  that  specify  class  composition;  3)  Protocol  diagrams  that 
specify  method  invocation  protocols;  and  4)  Instantiation  diagrams  that  describe  object  instantiation 
scenarios  that  assist  the  designer  in  validating  the  design. 

The  method  submodel  is  composed  of  the  following  two  diagram  types:  1)  Method  taxonomy  diagrams 
which  classify  method  types  by  behavior  similarity  and  2)  Client  diagrams  which  illustrate  clients  and 
suppliers  of  methods,  to  specify  functional  decomposition. 

IDEF4  Class  Submodel 

The  class  submodel  consists  of  inheritance  diagrams,  type  diagrams,  instantiation  diagrams,  protocol 
diagrams,  and  class-invariant  data  sheets.  The  class  submodel  shows  class  inheritance  and  class 
composition  structure. 

IDEF4  Inheritance  Diagrams 

Inheritance  diagrams  specify  the  inheritance  relations  among  classes.  For  example,  Figiu-e  2  shows  the 
class  Filled-rectangle  inheriting  structure  and  behavior  directly  from  the  classes  Rectangle  and 
Filled-object  and  indirectly  from  the  class  Object. 


?  Labd 


Object 


Figure  2.  Inheritance  Diagram 


IDEF4  Instantiation  Diagrams 

Instantiation  diagrams  are  associated  with  type  diagrams  in  the  class  submodel.  The  instantiation 
diagrams  describe  the  anticipated  situations  of  composite  links  between  instantiated  objects  that  are  used 
for  validating  the  design. 


Figure  3.  Type  Diagram 


IDEF4  Protocol  Diagrams 

Protocol  diagrams  specify  the  class  argument  types  for  method  invocation.  Figure  4  illustrates  a  protocol 
diagram  for  the  Fill-closed-object:  Polygon  routine-class  pair.  From  the  diagram,  the  reader  can  to  tell 
that  Fill-closed-object  will  accept  an  instance  of  the  class  Polygon  as  its  primary  (self)  argument  and  an 
instance  of  the  class  Color  as  a  secondary  argument,  and  will  return  an  instance  of  a  Polygon. 


Figure  4.  Protocol  Diagram 

The  IDEF4  Method  Submodel 

The  method  submodel  consists  of  method  taxonomy  diagrams,  client  diagrams,  and  data  sheets. 


Method  Taxonomy  Diagrams 

Method  taxonomy  diagrams  classify  method  types  by  behavioral  similarity.  A  method  taxonomy 
diagram  classifies  a  specific  system  behavior  type  according  to  the  constraints  placed  on  the  method  sets 
represented  in  the  taxonomy.  The  arrows  indicate  additional  constraints  placed  on  the  method  sets. 
Figure  5  shows  a  Print  method  taxonomy  diagram.  The  method  sets  in  the  taxonomy  are  grouped 
according  to  the  additional  contracts  placed  on  the  methods  in  each  set.  In  the  example,  the  first  method 
set.  Print,  has  a  contract  that  states  that  the  object  must  be  printable.  The  Print-text  method  set  contract 
would  have  constraints  such  as  "the  object  to  be  printed  must  be  text." 


Figure  5.  Method  Taxonomy  Diagram 


Client  Diagrams 

Client  diagrams  illustrate  clients  and  suppliers  of  routine-class  pairs.  Double-headed  arrows  point  from 
the  routine  that  is  called  to  the  calling  routine.  Figure  6  shows  a  client  diagram  where  the  Redisplay 
routine  attached  to  the  class  Redisplayable-object  calls  the  Erase  routine  of  the  Erasable-object  class  and 
the  Draw  routine  on  the  Drawable-object  class. 


Erasable-Object  Drawable-Object: 

Erase  Draw 

/ 

Redisplayable-Object: 

Redisplay 

Figure  6.  Client  Diagram 


Data  Sheets 

Because  IDEF4  is  not  just  a  graphical  language,  additional  information  about  the  inheritance  diagrams, 
method  taxonomy  diagrams  and  type  diagrams  is  maintained  in  detailed  data  sheets. 

Class  Invariant  Data  Sheets 

Class-invariant  data  sheets  are  associated  with  inheritance  diagrams  and  specify  constraints  that  apply  to 
every  instance  of  a  particular  class  of  objects.  There  is  one  class-invariant  data  sheet  for  each  class.  The 
constraint,  "Every  triangle  has  three  sides,"  is  a  class-invariant  constraint  on  the  class  Triangle. 

Contract  Data  Sheets 

Contract  data  sheets  are  associated  with  the  method  sets  in  method  taxonomy  diagrams  and  specify 
contracts  that  the  implemented  methods  in  a  method  set  must  satisfy.  There  is  one  contract  data  sheet  for 
each  method  set.  A  method  set  called  Pop,  for  popping  values  off  a  stack,  would  have  a  contract  that 
specified  that  it  would  not  attempt  to  "pop"  a  the  stack  if  the  stack  was  empty. 

Summary 

The  IDEF4  method,  developed  under  sponsorship  of  the  U.S.  Air  Force  Armstrong  Laboratory,  is 
designed  to  assist  in  the  correct  application  of  object-oriented  technology.  IDEF4  was  developed  by 
professional  object-oriented  designers  and  programmers.  The  most  important  reason  for  choosing  Ae 
IDEF4  method  is  that  it  views  object-oriented  design  as  part  of  a  larger  system  development  framework, 
rather  than  an  object-oriented  andysis  and  design  method  that  is  everything  to  everyone.  It  stresses  the 
object-oriented  design  procedure  over  the  graphical  syntax,  using  the  graphical  syntax  and  diagrams  as 
aids  to  focus  on  and  communicate  important  design  issues. 

KBSI  has  developed  an  automated  Object-Oriented  Design  tool,  SmartClass,  to  support  the  IDEF4 
method. 


This  page  was  last  updated  on  December  13, 1996. 
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